Почему я должен совершать, а не толкать в Git?

Я много гуглил, но не могу найти ответа.

Насколько я понял, фиксация должна применяться каждый раз при редактировании файла. Объясняя, что такое редактирование, почему и т. д.
Затем я должен нажать фиксацию, чтобы сделать серверную версию файла синхронизированной.

Чего я не могу понять, так это:

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

1 2

1 ответ:

Верно, что очень распространенная вещь, которую вы хотите сделать при работе с системой управления версиями: "запишите изменения в коммит, а затем отправьте этот коммит на удаленный сервер". На самом деле, большинство инструментов Git GUI, вероятно, позволят вам сделать это за один шаг. Однако логически "запись изменений в коммит" и "публикация коммита на сервере" являются различными операциями. В Subversion только сервер отслеживает коммиты, поэтому вы должны отправить ему изменения, чтобы это произошло. В Git локальный репозиторий сохраняет также отслеживаются коммиты, так что их можно разделить.

Теперь, хотя выполнение этих двух действий за один шаг является обычным рабочим процессом, существует много ситуаций, когда вы можете захотеть сделать что-то еще:

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

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

  3. Вы вносите свой вклад в проект, отправляя патчи по электронной почте. (Именно так было разработано ядро Linux, и, возможно, так оно и остается. Это требование фактически повлияло на дизайн Git в самом начале.)

  4. Вы делаете очень частые коммиты и, возможно, толкаете их в частный удаленный репозиторий для резервного копирования. Однако вы хотите использовать git rebase, чтобы очистить их перед публикацией - скажем, объединить новую функцию с исправлениями ошибок, найденных в начальной реализации, в один коммит.

  5. Простая причина: вы привязываетесь к ветви функции, которая еще даже не существует на удаленном сервере, поэтому вам не к чему стремиться. (Что также желательно, ветви функций необязательно должны публиковаться широко.)

В основном, Git стремится к максимальной гибкости для поддержки произвольно сложных рабочих процессов. Теперь вам это может не понадобиться, и в этом случае вы можете легко использовать GUI или небольшие скрипты оболочки, которые объединят все, что вам нужно.

8