Я точно в этой ситуации, но я выбрал немного более сложный, но не обязательно более сложный рабочий процесс с Git.
Сначала целью было научиться работать с ним, поэтому я немного изучил его. затем вернулся к описанному выше рабочему процессу.
Через некоторое время с этим стало трудно работать, так как возникли некоторые ситуации, и это дало мне вредные привычки, которые трудно было бы сломать, когда я присоединюсь к команде.
поэтому я согласился на следующее:
- Локальный репозиторий для работы.
- Мастер ветка как стабильный ствол для приложения
- Одна ветвь для каждой функции / рефакторинга, в основном одна ветвь для каждого значительного изменения, которое будет сделано.
- Слив обратно в магистраль, когда ветвь стабильна и все тесты пройдены.
Я также настраиваю учетную запись git hub, где я синхронизирую транк. Это позволило мне легко начать работать на разных компьютерах. Это было по необходимости, но позволило мне найти ошибки, которые были связаны с окружением, в котором я находился, и которого не было на других компьютерах. Так что теперь у меня есть привычка хотя бы один раз попробовать проект в другой «девственной» системе. Избавляет меня от головной боли, когда приходит время развертывания для клиента.
- Я отмечаю каждую версию, которая превращает его в GitHub как выпускаемую версию.
- Если он будет выпущен для клиента, я разветвлюсь из этой версии, чтобы создать вторую стабильную соединительную линию для исправлений ошибок, объявленных клиентом.
Сначала несколько веток казались излишними, но это ДЕЙСТВИТЕЛЬНО помогло. Я мог начать идею в ветке, поработать над ней некоторое время, и когда я начал бегать кругами, я сдался и начал другую ветку, чтобы работать над чем-то другим. Позже пришла идея, где я вернусь к полуобжаренной ветке и исследую эту идею. В целом это сделало меня НАМНОГО более продуктивным, так как я мог очень быстро проявить идеи и идеи и посмотреть, сработало ли это. Стоимость переключения веток с помощью GIT чрезвычайно низкая, что делает меня очень ловким с моей базой кода. Тем не менее, я все еще должен освоить концепцию rebase, чтобы очистить свою историю, но, поскольку я совсем один, я сомневаюсь, что мне действительно нужно. Выдвинул это как "приятно учиться".
Когда все ветвления усложнились, я исследовал опцию log, чтобы нарисовать дерево изменений и посмотреть, где какая ветвь.
Короче говоря, git не похож на SVN, CVS или (бррр) TFS. Ветвление очень дешево, и делать ошибки, которые уничтожат работу, на самом деле довольно сложно. Только однажды я потерял какую-то работу, и это было потому, что я сделал свои коммиты слишком большими (см. Дурные привычки выше). Если вы часто делаете коммиты, git будет вашим лучшим союзником.
Для меня git открыл мой разум для того, что на самом деле все о контроле над источниками. Все остальное раньше было просто попытками получить это, git - первое, что, на мой взгляд, получило это. Тем не менее, я не пробовал другие DVCS, вполне возможно, что это утверждение может быть расширено для всей семьи.
Последний совет, командная строка - твой друг. Нельзя сказать, что графические инструменты не очень хороши, скорее наоборот, но я действительно вздрогнул от мерзавца, когда спустился в командную строку и попробовал его сам. Это на самом деле очень хорошо сделано, легко следовать с очень всеобъемлющей системой помощи. Моя самая большая проблема была связана с ужасной консолью в Windows, пока я не нашел альтернативы.
Теперь я использую обе возможности: интеграцию Eclipse с Git, чтобы увидеть, что происходит в режиме реального времени, и выполнить некоторые операции, такие как diff, изучить историю файла и т. Д. И командную строку для ветвления, слияния, перемещения, получения и более сложных деревьев журналов. , некоторые базовые сценарии, и я никогда не был настолько продуктивным в отношении контроля над источниками, и у меня никогда не было такого большого контроля над своим источником.
Удачи, надеюсь, это помогло.