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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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