GIT для пользователей subversion (и др scm)

Git это еще одна системы для управления исходным кодом, аналогичная subversion, cvs и другим. Почему аналогичная, а не «новая», «быстрая» и тп? SCM (source code management) прежде всего инструмент, который позволяет выполнять операции необходимые для одного разработчика и команды в целом. При каждый инструмент имеет свои достоинства и недостатки.

В этой статье мы сосредоточимся на основных функциях, без сравнительного анализа (чтобы не повторять миллионы заметок в web). И покажем пример, как применять git при работе с subversion.

Основные функции которые нам необходимы: просмотр истории изменений, откат на любую точку, возможность создавать ветвление кода. Subversion (cvs) реализуют все эти требования, и многие разработчики ими пользуются ежедневно. Запуск этих команд приводит к выполнению алгоритмов на стороне сервера, что позволяет другим разработчикам видеть наши изменения. В этом подходе есть небольшая проблема: разработчик может захотеть сделать коммит промежуточной работы, без того что бы делить результаты с командой. Кроме этого, разработчик может захотеть сделать ветвь проекта для проверки идеи — итог тоже будет доступен всем.
Если в команде несколько человек, и каждый делает ветвь для каждой идеи то скоро мы получим сотни абсолютно бесполезных данных. Как итог этого, в командах существуют политики, когда и ка создавать ветки.
При этом инструмент ветвления по прежнему хорош и не стоит от него отказываться.
Как следствие стоит выбрать scm систему с поддержкой подобной функциональности. Эти системы по прежнему реализовывают теже команды, но при этом каждому разработчику дается собственный локальный репозиторий. При этом проект будет состоять из нескольких, распределенных репозиториев.
В этой статье мы не будем рассматривать процесс распределенной разработки.

Пользуемся subversion

Каждое утро вы выполняете 'svn update' для синхронизации локальной рабочей копии с центральным репозиторием. Потом получаете задачу через трекер и начинаете размышлять. Предположим, у вас есть два варианта решения проблемы и вам надо попробовать оба для выбора оптимального.
После кодирования первого варианта и тестирования вы получаете некоторые результаты. Теперь нужно попробовать второй путь. Тут возникает проблема, что делать с уже существующими изменениями? Сделать коммит мы не можем, так как решение не готово. Можно их закомментировать, сделать копию файлов на диске и тп, но в любом случае, это не очень удобно. В идеале было бы удобно иметь обе версии, и сделать коммит только для выбранного решения.
Тут и выходит на сцену git. Причем вы можете использовать его прозрачно для других участников команды.

Добавляем немного Git'а.

Для определенности будем держать наш проект в папке: ACME. Т.е. это рабочая копия с вашего subversion и она содержит папку .svn (.svn есть и во всех подпапках проекта).
'svn status' покажет текущее состояние.

Прежде всего нам надо сделать инициализацию. В ACME запустите:
git init
Это создаст локальный git репозиторий, который живет в папке .git. Обратите внимание — .git есть только в верхней папке проекта.

Запустите:
git status

Вы увидите, что все файлы отмеченны, как untracked. До добавления файлов исключим .svn
Откройте .git/info/exclude и добавьте: '.svn*'. Теперь git status не будет реагировать на .svn.
Добавьте весь проект в git:

git add .
git commit -am "initial file import"

В свою очередь svn status покажет папку .git. Так как она нам не нужна, игнорируем ее:

svn propset svn:ignore .git .

Теперь файлы проекта находятся в обоих системах: subversion и git. С точки зрения subversion процесс работы не изменился: вы используете update, commit и так далее.

Предположим у вас появилась идея для проверки, посмотрим как git нам поможет…
Запустите git status для проверки что состояние проекта updated. Если есть измененные или новые файлы (как результат svn update) просто добавьте их и сделайте git commit. Обратите внимание, вы находитесь в ветке master.
Можно создавать ветвь для вашей идеи.

git branch idea
git checkout idea

или

git checkout -b idea

git status покажет, что вы в новой ветке. git branch покажет все ветки.
Вы можете делать все изменения, делать коммиты, тесты и тп. В любой момент вы можете перейти в переведущую ветвь

git checkout master

и обратно

git checkout idea

Работая с веткой идеи вы можете создавать дополнительные ветки…

После внесения всех изменений и проверок было бы не плохо вернуть изменения в subversion. Во первых, вы можете запустить svn status для просмотра изменений и сделать svn commit. Это простейший путь, но я рекомендую сделать дополнительные шаги.
Мы сделаем ветку master зеркалом для subversion: т.е. svn update и svn commit мы будем запускать только будучи в master.
Как следствие, нам надо перенести изменения в master:

git checkout master
git merge idea

Так как мы не вносили изменений в master, то система сделает простой merge forward и мы сможем сделать коммит в svn.

Ненужную ветвь можно удалить:

git branch -d idea

Если вы что то напутали, всегда можно удалить .git и сделать init заново.

Вывод

В общем, git это практически идеальный инструмент для проверки идей, добавления новой функциональности и фиксинга багов. В качестве best practice рекомендуется создавать ветвь для каждого не косметического изменения. В продолжении стоит прочитать о командах: checkout, add, branch и merge.

Andrew Romanenco
andrew@romanenco.com
www.romanenco.com/gitsvn