2016-03-24 6 views
2

Мы используем 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, и многие из нас используют командную строку больше.

+0

Является ли разработчик B всегда одним и тем же лицом? разработчик B мог бы изменить настройку где-нибудь, что заставляет это произойти, тогда исправление будет сбросить настройку в нормальное состояние. –

+0

Разве Разработчик B обновляет свой код, чтобы получить совершенные изменения разработчика A, прежде чем совершать свой собственный код? – Harmelodic

+0

Нет, это определенно часть проблемы (что разработчик B не обновляет в первую очередь), но, в конце концов, существует фиксация разработчика A. Почему он исчезает? –

ответ

1

Сообщения о фиксации разработчика A, вероятно, не потеряны. Это приложение Github Desktop показывает коммиты.

Вы можете проверить, действительно ли вы потеряли фиксации, запустив git log --graph.

Если вы хотите, чтобы клиент, который показывает объединенные коммиты, вы можете использовать SourceTree или TortoiseGit.

Для получения более подробной информации см. this answer и this question.

+0

Да, ты прав. Я сам переключился на GitKraken, который мне очень нравится. –

2

Git merge не должен этого делать. Если вы не можете быть уверены в том, какие команды выполняет Git GUI (слияние, переустановка, сквош, ...) Я бы рекомендовал сделать ваш git merge с командной строкой, чтобы вы могли контролировать, что происходит.

Я, как правило, выступаю за командную строку Git из-за неясности и недоумения лексики, принесенных большинством графических клиентов Git.