git - пропускает определенные коммиты при слиянии

<p>я использую git уже около года и думаю, что это фантастика, но я только начал над второй версией проекта и начал новую ветку для него. я немного борюсь с лучшим способом справиться с ситуацией.</p><p>у меня есть две ветви, называемые, скажем, master10 (для v1) и master20 (для v2). я делал исправления ошибок в v1 на ветке master10 и разрабатывал новые вещи для master20. всякий раз, когда я исправляю ошибку, я объединяю ее с версией v2, проверяя master20 и выполняя <code>git merge master10</code>. все идет нормально.</p><p>однако теперь я внес изменение в v1, которое не нужно в v2, но я хочу продолжить объединение других исправлений ошибок. как мне сказать git пропустить этот конкретный коммит (или диапазон коммитов), но в дальнейшем я все еще хочу объединить другие исправления ошибок.</p><p>я думал, что <code>git rebase</code> может быть то, что мне нужно, но прочитал документ, и моя голова почти взорвалась.</p><p>я думаю, что мне нужно что-то вроде команды "git sync", которая сообщает git, что две ветви сейчас синхронизированы и в будущем объединяют только коммиты с этой точки синхронизации.</p><p>любая помощь приветствуется.</p>

<p>например, если вы хотите объединить большинство, но не все коммиты в ветке "maint", в "master", вы можете сделать это. это требует некоторой работы - как упоминалось выше, обычный вариант использования - объединение всего из ветки - но иногда случается, что вы внесли изменение в версию выпуска, которая не должна быть интегрирована обратно (возможно, этот код был уже заменен в мастере), так как вы это представляете? вот оно...</p><p>итак, давайте предположим, что к maint применено 5 изменений, и одно из них (maint ~ 3) не должно быть объединено с master, хотя все остальные должны быть. вы делаете это в три этапа: на самом деле объединяйте все до этого, говорите git пометить maint ~ 3 как слитые, даже если это не так, а затем объедините остальные. магия это:</p><pre><code>bash <master>$ git merge maint~4 bash <master>$ git merge -s ours maint~3 bash <master>$ git merge maint </code></pre><p>первая команда объединяет все <em>до</em> ваш проблемный коммит в мастер. сообщение журнала слияния по умолчанию объяснит, что вы объединяете "ветку 'maint' (ранняя часть)".</p><p>вторая команда объединяет проблемный коммит maint ~ 3, но опция "-s ours" говорит git использовать специальную "стратегию слияния", которая, фактически, работает, просто сохраняя дерево, в которое вы сливаетесь, и игнорируя коммиты вы полностью объединены. но он все еще делает новый коммит слияния с head и maint ~ 3 в качестве родителей, поэтому график изменений теперь говорит, что maint ~ 3 объединен. так что на самом деле вы, вероятно, захотите использовать опцию -m и для "git merge", чтобы объяснить, что этот коммит maint ~ 3 фактически игнорируется!</p><p>последняя команда просто объединяет оставшуюся часть maint (maint ~ 2..maint) в master, чтобы вы снова синхронизировались.</p>

<p>имхо, самое логичное, что нужно сделать, это <strong>объединить все, а затем использовать git revert (commit\_you\_dont\_want) для его удаления</strong>.</p><p>пример:</p><pre><code>git merge master git revert 12345678 </code></pre><p>если у вас есть несколько коммитов "to-ignore" или вы хотите отредактировать сообщение об отмене:</p><pre><code>git merge master git revert -n 123456 git revert -n abcdef git commit -m "... except commits 123456 and abcdef" </code></pre><p>тогда ваша история может выглядеть так:</p><pre><code>| ... except 123456 and abcdef |\ merge branch 'master' into 'your\_branch' </code></pre><p>если у вас есть конфликты, связанные только с этими фиксациями "игнорировать", вы можете использовать:</p><pre><code>git merge master -x ours </code></pre><p>таким образом, ваша версия будет сохраняться над другой. даже без сообщений об ошибках вы все равно можете "отменить" эти нежелательные коммиты, потому что они могут иметь другие изменения, которые не конфликтовали, и вы все равно их не хотите.</p><p>если у вас есть конфликты, связанные не только с фиксацией "игнорировать", вы должны разрешить их вручную, и вам, вероятно, придется разрешать их снова во время возврата.</p>

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

<p>походит на классический случай для 'git cherry-pick' <a href="https://git-scm.com/docs/git-cherry-pick">https://git-scm.com/docs/git-cherry-pick</a> это именно то, что звучит как</p>

<p>это своего рода реклама моего <a href="https://github.com/niamster/gitmerge">проекта</a> , которая в основном оборачивает процесс, описанный @araqnid.</p><p>это своего рода помощник, который вводит следующий поток git:</p><ul> <li>есть ежедневное/еженедельное уведомление об ожидающих слияниях из ветвей обслуживания в ветку dev/master</li> <li>сопровождающий филиала проверяет статус и сам решает, требуются ли все коммиты, и либо блокирует некоторые из них, либо просит разработчиков заблокировать себя. в конце концов ветка обслуживания сливается с upsteam.</li> </ul><p>цитата со страницы проекта:</p><blockquote> <p>в зависимости от рабочего процесса, можно иметь ветки обслуживания или специфичные для клиента наряду с главной веткой. эти ветви также называются ветвями lts.</p> <p>часто исправления попадают в ветки, в которых сообщалось об ошибке, и затем коммит возвращается обратно в основную ветку.</p> <p>общая практика состоит в том, чтобы все ветви были полностью синхронизированы с мастером, то есть вы хотите увидеть четкую дельту между конкретной веткой и мастером, чтобы понять, содержит ли мастер все функции и исправления ошибок.</p> <p>однако иногда вам не нужны определенные коммиты, потому что они зависят от клиента и не будут видны другим пользователям. или ваша основная ветвь настолько разошлась, что для решения проблемы требуется совершенно другой подход, или, что еще лучше, проблема больше не присутствует.</p> <p>также в случае выбора вишни из мастера в ветвь обслуживания полученный коммит должен быть заблокирован в мастере.</p> </blockquote>

<p>вместо <code>revert</code> или <code>cherry-pick</code> для этого случая вам нужно получить git, чтобы учесть изменения, которые вы пропускаете, чтобы быть старше, чем те, которые вы сделали.</p><p>так:</p><ol> <li>объединить последний коммит до коммитов, которые вы хотите пропустить. это, конечно, объединит все коммиты ранее. <code>git merge ccc</code></li> <li>объединить коммиты, которые вы хотите пропустить. <code>git merge fff --no-commit</code></li> <li>произведите слияние, отмените все изменения, отмените все изменения. (возможно, для этого есть надежные команды, но я бы просто выполнил эту часть в пользовательском интерфейсе - как вы знаете, как)</li> <li>завершить пустое слияние <code>git merge --continue</code></li> <li>объединить коммиты после того, кого вы хотели пропустить. <code>git merge source-branch-head</code></li> </ol><p>после шага 4 git будет считать вашу ветку более новой, чем эта фиксация, поскольку вы уже имели дело с ней (решив сохранить ваши версии вещей).</p>

<p>создайте третью ветку для изменений, которые вы хотите в master10, но не в master20. всегда считайте master10 своим "хозяином", самой стабильной веткой из всех. ветвь, с которой все остальные ветви должны постоянно синхронизироваться.</p>