Почему бы вам не зафиксировать объединенные изменения немедленно?

16

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

Я делаю учебный документ, который проходит через Git и SourceTree и объясняет каждый шаг процесса. В процессе извлечения диалоговое окно SourceTree позволяет выбрать параметр «Немедленно зафиксировать объединенные изменения». Я понимаю, что это делает и почему это полезно. Чего я не понимаю, так это того, почему никто не захочет использовать эту функцию.

Может ли кто-нибудь объяснить, почему вы не хотите, чтобы ваши объединенные изменения совершались автоматически? Я пытаюсь понять причину, чтобы лучше объяснить полезность функции и понять, какие подводные камни следует искать в будущем.

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

Дэвид К
источник
Возможный дубликат git / other VCS - как часто совершать коммиты?
комнат
1
Вы хотите веские причины? Потому что я могу привести множество причин отложить проверку кода, о которой, как я слышал, люди говорят в дикой природе, но немногие из них являются вескими причинами.
whatsisname
Единственная причина, о которой я могу думать, - это когда слияние не удается из-за конфликтов слияния. Но SourceTree не будет фиксироваться, если это все равно произойдет.
Роберт Харви
На заметку: зачем ты пишешь свой урок? У bitbucket уже есть отличный учебник. confluence.atlassian.com/bitbucket/…
winkbrace
@winkbrace Мы не используем Bitbucket; мы держим все в локальной сети. Я ссылаюсь на замечательный учебник Атлассиана , но мне хотелось чего-то более краткого, чтобы я мог передать людям, которые были новичками в Git и управлении версиями. Это действительно скорее вводное и процедурное «это то, как и почему вы совершаете / push / pull / etc», чтобы люди могли взяться за дело.
Дэвид К

Ответы:

26

Я не хотел бы использовать эту функцию.

Тот факт, что не было никаких конфликтов, в значительной степени означает, что изменения, объединяемые в моей ветке, примерно не совпадают с теми строками кода, которые я сделал. Это не значит, что эти изменения совместимы с моими изменениями. Это не означает, что код будет компилироваться, или что код будет работать, или что тесты пройдут.

Другими словами, используя эту опцию, я потенциально получаю ложную фиксацию кода, которая может быть не в хорошем состоянии и требует исправления новой фиксации. В любом случае, поскольку я делаю эту работу, и поскольку я никогда не должен выдвигать этот ложный коммит вверх по течению, даже по ошибке (Боже упаси, кто-то может затем объединить это в какую-то другую ветвь!), Я не вижу причин создавать этот коммит в первом место.


источник
Предположительно, вы создаете ветви функций, а не объединяете каждое небольшое изменение с основной веткой. Слияния вряд ли вызовут конфликты в ветви функций, если несколько человек не работают в одном классе в одной ветви функций.
Роберт Харви
4
@RobertHarvey Да, но я часто объединяю основную ветку с моей веткой. В вашем комментарии есть скрытое предположение, что разные функции будут естественным образом затрагивать разные классы / модули, но не всем везет. К счастью, у вас где-то есть класс Бога, к которому нужно прикоснуться каждому, кто что-то делает, и вы ничего не можете с этим поделать. Также есть сквозные функции (обновите некоторую библиотеку, из-за которой нужно изменить одну из каждых 10 строк кода ...) Я знаю аргумент «попытаться не попасть туда», но что, если вы уже там? Береженого Бог бережет.
2

После слияния могут быть изменения в файлах локального репо. Эти изменения не будут автоматически подтверждены локально, если вы не установили «Принять объединенные изменения немедленно».

Если вы не установите эту опцию, файлы появятся в SourceTree как незафиксированные изменения.

Это потому, что сам Git не выполняет коммит, если вы явно не скажете это, а SourceTree является графическим интерфейсом Git. «Commit слитых изменений немедленно» вариант не столько варианты, так как это команда быстрого доступ.

Таким образом, причина не хочет использовать эту функцию самоочевидно: вы хотите , чтобы выполнить фиксацию вручную, или нет вообще.

Допустим, вы перетащите мастер в свою ветку функций. Сотрудник работает в другой ветви функций. Этот сотрудник имеет историю ломать вещи. Слияние содержит изменения общего общего кода, сделанные этим сотрудником. Таким образом, вы - вместе с остальной частью команды - не вносите объединенные изменения, пока не будете уверены, что этот сотрудник не внес изменения, которые повлияют на вашу работу.

Просто потому, что в теории нет веской причины не использовать эту функцию, на самом деле может быть множество веских причин. Что касается вашего урока, я бы просто сказал, что «99 раз из 100, это вариант, который вы хотите использовать». Я не думаю, что вам действительно нужно вдаваться в подробности о том, чтобы не использовать его, особенно если другие новички в управлении версиями. Это все зависит от того, насколько глубоко вы намереваетесь использовать этот урок.

Марк Беннингфилд
источник
2

Если вы используете ловушку пост-фиксации для автоматической отправки ваших фиксаций (как в /programming//a/7925891/6781678 ), вам может понадобиться эта опция, чтобы избежать принудительной фиксации сомнительного качества.

Я бы никогда не использовал.

Philippe
источник