Git: возникли проблемы при попытке сохранить чистое дерево истории - PullRequest
2 голосов
/ 29 декабря 2011

У меня есть репозиторий git, над которым работают несколько человек.Я настроил branch.master.rebase = true и branch.master.mergeoptions = --no-ff, но столкнулся с проблемой:

Кто-то пытался объединить ветвь функций в master.Слияние прошло успешно, и git сказал, что ветка была на 30 коммитов раньше, чем origin / master.Когда он попытался отправить изменения, git отклонил push, потому что там были изменения в пульте, поэтому ему пришлось сделать git pull.Когда он сделал тягу, git сделал ребаз для коммитов, которые были объединены с мастером, и теперь было всего 29 коммитов перед мастером.

Я считаю, что коммит слияния был потерян, потому что после ребазированиякоммиты, которые были применены как новые коммиты, а не коммиты, полученные из ветви функций.

После нажатия дерево было таким:

* c3'(head, master, origin/master)
* c2'
* c1'
|  * c3 (feature_branch, origin/feature_branch)
|  * c2
|  * c1
| /
*

Это то, чего я пытался достичь:

* c4 (head, master, feature_branch, origin/master)
| \
|  * c3 (origin/feature_branch)
|  * c2
|  * c1
| /
*

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

Какие-нибудь советы о том, что я могу сделать, чтобы избежать этого?

Спасибо,

Редактировать: Эта статья описывает мою проблему: http://notes.envato.com/developers/rebasing-merge-commits-in-git/

Теперь я знаю о опции --preserve-merges для git rebase, ноЕсть ли способ сделать эту опцию по умолчанию?

В противном случае разработчики должны будут git fetch и git rebase origin/master вместо просто git pull.

Ответы [ 2 ]

3 голосов
/ 29 декабря 2011

Содержание истории в чистоте переоценивается много раз. Природа DAG (направленного ациклического графа) позволяет легко устанавливать манипуляции со ссылками на конкретные коммиты (sha1s, теги, ветви, древовидную структуру и т. Д.), Чтобы увидеть, какие коммиты уже были объединены или какие еще должны быть. Неподтверждение сохраняет историю более точным способом, который показывает, что развивалось параллельно и когда эти усилия были объединены.

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

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

Изначально мне нравилось сохранять свою историю красивой, аккуратной и линейной. По мере того, как я использовал Git все больше и больше, стало очевидно, что использование инструментов, не относящихся к DVCS, таких как SVN, было перенесено на него.

3 голосов
/ 29 декабря 2011

Почему вы используете branch.master.rebase = true, если хотите сохранить всю историю ветвлений?

...