Git для развития одного человека

Question

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

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

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

Что я делаю не так? Или git / системы контроля версий не предназначены для разработки для одного человека?

Answer 1

Если вы только начинаете с контроля версий, для проекта с одним человеком, то сначала не беспокойтесь обо всех этих рабочих процессах и т. Д.Во-первых, привыкните к фиксации.

Вы только что запустили свою программу и протестировали что-то, и это сработало?Отлично, коммит.Собираетесь сделать что-то, что вы не совсем уверены, сработает?Commit.Фиксируйте рано и часто.Хорошая вещь в git - коммиты отменяются, если вы выбрали плохое место для фиксации (подсказка: если он не компилируется, это, вероятно, плохое место - но есть исключения из этого, когда вы освоитесь с git rebase -i иgit add -i (хотя это довольно продвинутый инструмент, так что сначала привыкните к основам! (Вложенные скобки - это весело!))).

Теперь о переключении фокуса - в git есть ряд полезных инструментов для этого..

Например, если вы хотите исправить ошибку, но у вас уже есть куча другой работы ...

git stash save

Затем Git принимает все незафиксированные изменения, сохраняет их и отменяетдо последнего коммита.Вы можете исправить ошибку, протестировать, зафиксировать, а затем

git stash pop

Все эти изменения затем будут применены поверх исправления.

Если вы работаете с небольшой функцией,но потом поймете, что это на самом деле довольно сложно, и вы, вероятно, сделаете это несколько раз ...

git checkout -b mynewbranch

И вот, вы - в новой ветке.Вы можете в любой момент вернуться в другую ветку с помощью

git checkout someotherbranch

. Вы можете использовать это вместе с git stash, чтобы сохранить незафиксированные изменения, а затем переключиться на другую ветку, чтобы сделать что-то совершенно другое.И когда вы захотите вернуться, git checkout mynewbranch.

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

git add -i
# select what changes to include
git commit # commits only what you selected

Это благодаря индексу git - git add -i позволяет вам выбрать, вплоть до уровня отдельной строки, что именно копировать из рабочей копии в индекс, а затем git commit сохраняет его каккоммит.Делая это, вы можете очень быстро и легко выявлять мелкие исправления из путаницы других изменений.Однако обратите внимание, что это означает, что вы только что зафиксировали что-то, что никогда не компилировалось и не тестировалось в этой форме;поэтому требуется некоторая осторожность, чтобы не фиксировать что-то полностью сломанное (как правило, следует избегать фиксации полностью сломанного кода, потому что он ломает git bisect - очень удобный инструмент для отслеживания регрессий).

Как только вы привыкнете к этому основному потоку, вы можете начать добавлять к нему некоторый процесс.Например, вы можете оставить ветку v1.x для исправлений только в серии 1.x.Или что угодно.Используйте рабочий процесс, который работает для вас.