github слияние рабочего стола скрывает комментарии

Мы используем Github Desktop (ранее Github для Windows) в качестве нашего клиента Git. У нас часто бывает следующая ситуация:

Разработчик А делает кучу обновлений с прекрасными поясняющими сообщениями. Разработчик B работал в той же ветке и впоследствии делает коммит с сообщением.

Коммит разработчика Б с сообщением отображается в журнале git, и после него мы получаем фиксацию слияния от разработчика Б с автоматическим сообщением "merge branch...". Коммит слияния содержит все изменения разработчика А, но прекрасные сообщения разработчика А исчезли. Кажется, что это поведение несколько изменилось — раньше это случалось очень редко, а теперь, кажется, происходит постоянно.

(Трудно найти актуальную информацию о том, что именно делает кнопка «Синхронизировать» в Github Desktop, но я нашел ссылка, предполагающая, что раньше она выполняла git pull --rebase, а затем изменилась. Похоже, это согласуется с тем фактом, что проблема с фиксацией слияния намного хуже, чем раньше. )

Итак, мой вопрос: есть ли способ предотвратить потерю сообщения фиксации разработчика А?

EDITED TO ADD: похоже, проблема двоякая: 1) наши разработчики не всегда делают тягу перед фиксацией, что приводит к коммитам слияния. Исходные коммиты не теряются, но не видны. 2) То, как Github Desktop отображает журнал, показывает коммиты слияния, но не показывает исходную фиксацию. Вот комментарий, который я получил по электронной почте от команды Github Desktop:

Если копнуть глубже, похоже, что коммиты скрыты из-за флага --first-parent, который мы используем при отображении истории в GitHub Desktop. В настоящее время нет способа изменить это поведение.

Вот некоторые из причин, по которым мы это делаем, которыми поделился разработчик GitHub Desktop:

«GitHub Desktop оптимизирован для GitHub Flow. В этой модели слияния почти всегда представляют собой либо (1) слияние ветки с веткой по умолчанию с помощью запроса на вытягивание, либо (2) ветку, обновляемую из ветки по умолчанию.

В первом случае наиболее полезно видеть, какие запросы на включение были объединены, а не отдельные коммиты, из которых состоит этот запрос на вытягивание. Мы думаем, что пулл-реквесты потрясающие и очень полезные для понимания истории, поэтому мы хотим расставить им приоритеты.

Во втором случае просмотр коммитов, пришедших со слиянием, только скрывает изменения в ветке. Полезнее всего видеть коммиты, уникальные для ветки».

В конечном итоге мы чувствуем, что, вероятно, Github Desktop нам не подходит — я лично перешел на GitKraken, и многие из нас больше используют командную строку.


person Jacob Mattison    schedule 24.03.2016    source источник
comment
Разработчик B всегда один и тот же человек? разработчик B мог бы где-то изменить настройку, из-за которой это произошло, тогда исправление вернуло бы настройку к нормальному состоянию.   -  person Thibault D.    schedule 24.03.2016
comment
Обновляет ли разработчик Б свой код, чтобы получить изменения, зафиксированные разработчиком А, перед фиксацией собственного кода?   -  person Harmelodic    schedule 24.03.2016
comment
Нет, это определенно является частью проблемы (что разработчик Б не обновляет первым), но, в конце концов, фиксация разработчика А существует. Почему он исчезает?   -  person Jacob Mattison    schedule 24.03.2016
comment
Неизменяемость коммитов — это не столько правило, сколько математический факт. Это не слияние, кто-то добавляет дополнительные коммиты и отказывается от прекрасной работы разработчика А.   -  person jthill    schedule 24.03.2016


Ответы (2)


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

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

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

См. этот ответ и этот вопрос для более подробной информации.

person filhit    schedule 03.06.2016
comment
Да, ты прав. Сам я перешел на GitKraken, который мне очень нравится. - person Jacob Mattison; 03.06.2016

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

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

person Thibault D.    schedule 24.03.2016