Методы выборочного представления основного репо

Question

Скажите, что вы клонировали локальное репо из удаленного проекта с открытым исходным кодом (например, на Github). Вы вносите изменения в свои местные филиалы репо и т. Д.

Вы имеете в виду следующую цель: некоторые из внесенных вами изменений предназначены для ваших собственных целей и не будут возвращены в основное репо, другие изменения представляют интерес для сообщества, такие как исправления ошибок и добавление функций и те, которые вы хотели бы внести в основное репо.

Итак, на основе этого предположим две основные ветви: dev-proj для всех изменений, dev-comm с подмножеством, которое будет возвращено в основное репо.

В общем случае вы знали бы, что данный набор изменений перейдет в dev-comm или нет, поэтому вы можете выделить их в ветку.

Однако существуют запутанные случаи, когда вы не хотите, чтобы ваше разветвление было продиктовано тем, должны ли изменения быть внесены в исходное положение или нет.

Возьмем, к примеру, случай локализации веб-приложения - изменения в переводе и представлениях и т. Д. Вы создаете ветку для нее, и вы намерены сохранить ее конфиденциальной, но, работая над ней, вы обнаружите, что есть проблемы с i18n с исходным кодом, поэтому вы исправляете их как часть своей работы в этой ветке. И эти изменения WRT к i18n, которые вы хотели бы выделить и вернуться к основному репо.

Мой вопрос: выбрал ли вишню лучший способ справиться с этой ситуацией - я заинтересован , это привлечет некоторое отвлечение, чтобы попытаться детализировать коммиты, и что произойдет, если я сделаю по ошибке фиксацию, которая включает в себя кусок частных изменений и изменений сообщества, тогда мне придется попытаться применить исправления для этого. Или есть какая-то лучшая техника, даже если она включает в себя некоторые ручные элементы.

Edit: Я поясню с грубым эскизом: р для местного проекта и с для изменения означало специально для толкания вверх для сообщества:

    Ep--Fc--Gp--Hc--Ipc(commit not granular!)--Jc topicA 
       /
    A--B--C devProj 
     | 
     \ Q--R devComm 
         | 
         \ Fc--Hc--I2c--Jc topicAcomm 

Работая над Топикой, мы не хотят беспокоиться о том, какие части предназначены для сообщества. Но в конце этого мы хотели бы иметь что-то вроде topicAcomm, которое можно объединить в devComm и нажать вверх по потоку.

Мой вопрос заключается в том, является ли вишневый сбор способ справиться с этим, что кажется правдоподобным способом проверки документов/учебников. Или есть некоторые другие трюки, такие как аннотирование кода позже, возможно, или некоторые другие трюки, о которых я не знаю.

Наличие случайного смешения является лишь одной проблемой, которая может возникнуть.

Answer 1

Вы можете принять некоторые идеи от original git branches management, также подробно описанные в «gitworkflows Manual Page».

Я предпочел бы изменить порядок историю вашей темы отрасли, чтобы сделать слияние с публичной властью, а не полагаться на индивидуальном вишневый сборе (который может оказаться проблематичным позже: см «How to merge a specific commit in git»)

Любая rebase заставит вашу команду сбросить свою ветку темы в ветку новых заказов, но это более управляемо, чем задавать сообщество (гораздо большая группа людей), чтобы сбросить что-либо.

Один трюк для автоматического переназначения является git rebase --interactive --autosquash, которая будет изменять порядок и группы коммитов (см «Trimming GIT Checkins/Squashing GIT History».

Answer 2

Взгляните на «git rebase --onto ...». Для вашего примера подумайте об этом как о двух шагах: 1) изолируйте свои изменения «i18n» на своей ветке с «rebase» и 2) объедините эту ветку с dev-proj. От 'мерзавца помощи перебазироваться', один из примеров:

If we have the following situation: 

             H---I---J topicB 
             /
         E---F---G topicA 
         /
    A---B---C---D master 

    then the command 

     git rebase --onto master topicA topicB 

    would result in: 

         H'--I'--J' topicB 
        /
         | E---F---G topicA 
         |/ 
    A---B---C---D master 

Тогда из этого можно объединить topicB на мастер (DEV-Proj) и обратно на topicB (Dev-Comm).