git commit для всех ветвей

Question

Если я исправил ошибку в файле в ветке branch_a, которая должна быть применена ко всем ветвям. Есть ли способ применить изменения ко всем филиалам без необходимости индивидуальной проверки филиалов.

git commit -m 'commit msg' # on branch a 

git checkout branch_b 
git cherry-pick branch_a 

git checkout branch_c 
git cherry-pick branch_a 

Что я хотел бы иметь это git commit --to-all-branches, который пытается распространить изменения во всех отраслях, если это возможно.

Редактировать

Чтобы прояснить чуток мою ситуацию, я пишу код для вычислительных задач. Часто я оказываюсь в ситуации, когда неясно, какой подход лучше всего решает данную проблему. Поэтому я создаю ветку. Эти отрасли, как правило, расходятся и больше похожи на вилки. Однако, чтобы сохранить все файлы на месте, я просто использую один репозиторий git с несколькими ветвями. В ситуации с ошибкой, относящейся ко всем ветвям/вилкам, я искал прочь, чтобы автоматически обновлять все ветви.

Answer 1

Нет, или, строго говоря, «да, но это так же работает любым другим способом». Новые коммиты всегда добавлены в «текущую ветку», , даже если это «отдельная головка». (Ниже я покажу способ сделать это с государством «отдельностоящая ГОЛОВА», хотя, если вы добавляете фиксации существующих отраслевых кончиков, это более работы, чем просто проверить их.)

Предполагая у вас есть что-то вроде этого:

A-B-C   <-- br1 
    \ 
    D F  <-- br2 
    \/
     E 
     \ 
     G  <-- br3 

и у вас есть некоторые исправить X, которые должны быть применены на вершине C, F и G дать:

A-B-C-X1  <-- br1 
    \ 
    D F-X2 <-- br2 
    \/
     E 
     \ 
     G-X3 <-- br3 

(обратите внимание, что все 3 Xn коммиты отличаются друг от друга, так как у них разные родители), тогда вы должны добавить «patch X», чтобы зафиксировать C, а затем добавить «patch X», чтобы зафиксировать F, а затем добавить «patch X» для фиксации G.

Обратите внимание, что нет никакой гарантии, что, например, переход от C к X1 точно соответствует изменению от F к X2 здесь, либо. Вы можете построить любой из трех Xn, совершая первый, обычным способом. Затем (как и в вашем вопросе) вы просто переходите к другим ветвям и git cherry-pick для создания (и, возможно, разрешения конфликтов) других X -es. Но вы должны быть «на» те отрасли, чтобы добавить фиксаций к ним, так:

$ git checkout br1 
... make fix, "git add", "git commit" to create X1 

$ git checkout br2 
Switched to branch 'br2'. 
$ git cherry-pick br1 # take diff of `C`-vs-`X1`, apply to `F` to make `X2` 
... etc 

Повторите эти действия для всех ветвей, к которым пластырь необходимо скопировать (и, при необходимости, модифицированные в соответствии эту ветку).

---

Есть альтернативы для этого. Например, предположим, что ветвь br1 на самом деле в порядке, и то, что вы обнаружили, это то, что commit E не работает и должен быть исправлен, что влияет на фиксацию F и G.Предположим далее, что ни у кого ни один не имеет совершает F и G -или, вы готовы заставить тех, кто сделать, имеют эти две фиксации, чтобы выполнить кучу работы, чтобы оправиться от того, что вы собираетесь делать. В этом случае вы можете проверить фиксацию D и совершить новую фиксацию, E', которая отходит от D. Давайте нарисуем исходную точку, оставив A до C. Мы git checkout D (его SHA-1, или, что то же самое с этим графиком, с помощью br2~2 назвать его), чтобы получить "обособленная голова" там:

D  <-- HEAD 
| 
| F <-- br2 
\/
    E 
    \ 
    G <-- br3 

Сейчас:

$ git cherry-pick -n br2^ # make a copy of E but don't commit yet 
# edit to fix it 
$ git commit    # make new commit E' that's fixed 

После фиксации отделки, мы имеем это (по-прежнему с «отделенной HEAD):

E' <-- HEAD 
/
| 
| 
D 
| 
| F <-- br2 
\/
    E 
    \ 
    G <-- br3 

Теперь мы можем скопировать совершить F в F':

$ git cherry-pick br2 

дает:

F' <-- HEAD 
/
    E' 
/
| 
| 
D 
| 
| F <-- br2 
\/
    E 
    \ 
    G <-- br3 

Теперь мы готовы сделать br2 обратитесь к совершению F':

$ git branch -f br2 HEAD 

даяние:

F' <-- HEAD, br2 
/
    E' 
/
| 
| 
D 
| 
| F [abandoned] 
\/
    E 
    \ 
    G <-- br3 

(Это " или строго говорить ing ", которую я написал выше: вы можете добавлять фиксации в репозиторий, а затем перемещать метки ярлыков, чтобы они маркировали новые цепочки фиксации, а не их старые. Все добавленные коммиты перемещаются HEAD: это просто, если HEAD является ссылкой на ветку, они также переместите ветку на один шаг вперед, как вы работаете. Имея HEAD, обратитесь к ветке, это «нормальный» способ работы, но вы можете подделать его после факта в режиме «снятый HEAD» с помощью git branch -f. В этом случае, я делаю что строить новый br2 без использования филиала имени, затем переместить имя ветви на новую цепочку фиксаций, как только он будет готов.)

Теперь нам нужно скопировать G в G' , есть G' до E'. Вот шаги:

$ git checkout br2^  # get back on E' as a detached HEAD 
[git says stuff here about moving the detached HEAD] 
$ git cherry-pick br3 # copy commit G 
$ git branch -f br3 HEAD # and move br3 label here 

(это то, что мы сделали для копирования F в F', более или менее) дает:

F' <-- br2 
/
    E' 
/\ 
| G' <-- HEAD, br3 
| 
D 
| 
| F [abandoned] 
\/
    E 
    \ 
    G [abandoned] 

После того, как вы все сделали, вы должны, вероятно, git checkout somebranch получить назад «на ветке», и вдали от этого «отдельно стоящего ГОЛОВНОГО» состояния.

Как отмечено в комментариях, необходимо применить патч как широко распространенный (это слово?), Поскольку это говорит о том, что, возможно, что-то не так со всем процессом. (Но это то, что фиксирует «нулевую ошибку дня», похоже, когда у вас есть куча разных продуктов, которые все используют кодовую базу с ошибкой «день-ноль».)

Answer 2

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