Рабочий процесс контроля версий

Question

Я кодирую уже более 10 лет, но никогда не использовал никакой системы контроля версий.Я хочу изучить и начать использовать GIT, я собираюсь вскоре прочесть книгу Apress ProGIT.

Этот вопрос не о том, как использовать команду GIT, а о том, в каких шагах вызывать их.

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

Я обычно работаю со многими файлами одновременно, поэтому я пытаюсь выяснить, каждый раз, когда я делаю измененияв файл и нажмите save`, это время, когда я должен зафиксировать этот файл, или это больше похоже на то, что я работал над этими 5 файлами сегодня, в конце дня я могу зафиксировать все эти 5 файлов?

Я знаю, что многие люди используют командную строку для GIT, поэтому я не могу представить, чтобы они возвращались туда и обратно каждый раз, когда меняли файл.

Я понимаю, что это может звучать просто, и это так, но помните, я никогдаЯ использовал любой вид управления версиями, так что я немного растерялся, я имею в виду, что все статьи и руководства посвящены правильному синтаксису / командам и предполагают, что у вас есть другие знания по управлению версиями (что делает большинство людей)

Answer 1

С git, или с любым DVCS в этом отношении, дело в том, что коммит и подталкивание ваших коммитов вверх по течению - это совершенно разные понятия. Если, например, в SVN фиксация означала, что все видят вашу ревизию, в git таких забот нет. Фиксируй когда хочешь, сколько хочешь. Продвигайте изменения вверх по течению, как только вы будете достаточно уверены в них.

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

Хорошее эмпирическое правило заключается в том, чтобы сделать коммит, как только у вас будет стабильная новая версия кода, так что, если кто-нибудь проверит эту ревизию, материал не будет сломан. (Это также важно позже, если вы планируете выполнить git bisect, который является расширенным методом отладки, но пока игнорируйте это.)

Есть несколько действительно хороших ресурсов, которые вы можете изучить на примере:

• http://nvie.com/posts/a-successful-git-branching-model/
• http://gitready.com/

Answer 2

Я обычно работаю со многими файлами одновременно, поэтому я пытаюсь выяснить, каждый ли раз, когда я делаю изменение в файле и нажимаю save`, это время, когда я должен зафиксировать этот файл, или это больше похоже наХорошо, я работал над этими 5 файлами сегодня, и в конце дня я могу зафиксировать все эти 5 файлов?

При работе с VCS лучше подумать об изменениях с точки зрения возможностей (или исправлений, есливы работаете над проблемой), а не только файлы.Даже если вы изменили только один файл, но представили новую завершенную функцию, и, если вы работаете в команде, готовы поделиться с кем-то другим, пришло время сделать коммит.С другой стороны, если вы уже изменили 20 файлов, но все еще занимаетесь внедрением новой функции, лучше отложить принятие до завершения.

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

И исключением для меня обычно является проект, который только начался, и вас это не волнуетБудущее, поскольку оно только начинается, и проект еще не имеет хорошей структуры, и, скорее всего, многое изменится в ближайшем будущем.В этом случае мои коммиты иногда становятся огромными и не очень хорошо структурированными.

Answer 3

Проверьте эту ссылку: Git для начинающих: полное практическое руководство

Я нашел его очень полезным.Это заставило меня понять, как это работает.