Мы используем Github Desktop (ранее Github для Windows) как наш клиент Git. Мы часто имеем следующую ситуацию:github desktop merge commit hiding comments
Разработчик A совершает кучу обновлений с прекрасными пояснительными сообщениями. Разработчик B работает в той же ветке и совершает фиксацию после этого с сообщением.
Комбинация разработчика B с сообщением отображается в журнале git и после этого мы получаем коммитовую фиксацию от разработчика B с автоматическим сообщением «слияние ветки ...». Согласование слияния содержит все изменения разработчика A, но прекрасные сообщения разработчика A исчезли. Похоже, что это поведение несколько изменилось - оно случалось очень редко, и теперь, похоже, все время происходит.
(Это трудно найти последнюю дату информацию о том, что кнопка «Синхронизировать» в Github Desktop делает, точно, но я нашел a reference предполагая, что он имел обыкновение делать git pull --rebase
, а затем изменили. Это, кажется, соответствует с тем фактом, что эта проблема слиянием слияния намного хуже, чем раньше.)
Итак, мой вопрос: есть ли способ предотвратить потерю сообщения об объявлении разработчика А?
EDITED TO ADD: Кажется, что проблема двоякая: 1) наши разработчики не всегда делают попытку до совершения, в результате чего совершаются слияния. Исходные коммиты не теряются, но не видны. 2) То, как Github Desktop отображает журнал, показывает фиксацию слияния, но не показывает первоначальную фиксацию. Вот комментарий, который я получил по электронной почте от команды Github Desktop:
Копания в это дальше, это выглядит как фиксации в настоящее время скрыты из-за --first-родительского флаг, который мы используем при показе история в GitHub Desktop. В настоящее время нет способа изменить это поведение .
Вот некоторые из рациональная позади, почему мы делаем это, что разработчик GitHub Desktop совместно:
«GitHub Desktop оптимизирован для GitHub потока В этой модели объединяет почти всегда представляют собой либо (1). филиал получать объединен в филиал в по умолчанию с помощью запроса тягового или (2) филиал обновляется с ветви по умолчанию.
в первом случае, это наиболее полезно узнать, какие тянуть запросы были были объединены, не индивидуальные коммиты, которые составляют этот запрос на извлечение. Мы считаем, что запросы на получение потрясающие и очень полезны для понимания истории, поэтому мы хотим расставить приоритеты.
Во втором случае, видя коммиты, которые пришли с слиянием, только скрывает изменения на ветке. Это наиболее полезно, чтобы увидеть коммиты, которые являются уникальными для филиала «
Мы в конечном итоге чувство, как, вероятно, Github Desktop не очень подходит для нас. - Я лично перешел на GitKraken, и многие из нас используют командную строку больше.
Является ли разработчик B всегда одним и тем же лицом? разработчик B мог бы изменить настройку где-нибудь, что заставляет это произойти, тогда исправление будет сбросить настройку в нормальное состояние. –
Разве Разработчик B обновляет свой код, чтобы получить совершенные изменения разработчика A, прежде чем совершать свой собственный код? – Harmelodic
Нет, это определенно часть проблемы (что разработчик B не обновляет в первую очередь), но, в конце концов, существует фиксация разработчика A. Почему он исчезает? –