Основные команды.

Обновить. Время от времени вы должны обеспечивать внесение изменений, сделанных другими, в вашу рабочую копию. Процесс внесения изменений с сервера в вашу локальную копию называется обновлением. Обновляться может одиночный файл, набор выбранных файлов или рекурсивно целые иерархии папок. Для обновления выберите файлы и/или папки, которые вы желаете обновить, щёлкните правой клавишей мыши и выберите из контекстного меню Проводника TortoiseSVN->Обновить.

Фиксировать. Отправка изменений, сделанных в вашей рабочей копии, называется фиксацией. Но перед фиксацией вы должны убедиться, что рабочая копия находится в актуальном состоянии. Можно либо сразу использовать TortoiseSVN -> SVN Обновить..., либо можно сначала вызвать TortoiseSVN->Проверить на наличие изменений для просмотра файлов, которые были изменены локально или на сервере.

Конфликты.

П.4.6 из инструкции.

Просмотр различий.

П.4.10.

Ответвления и метки.

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

Другой возможностью систем управления версиями является способность помечать частные ревизии (например, версию выпуска), так что вы сможете в любое время воссоздать конкретную сборку или окружение. Этот процесс известен как создание метки.

Выберите папку в рабочей копии, которую вы желаете скопировать в ответвление или пометить, затем выберите команду TortoiseSVN->Ответвление/Метка. По умолчанию, целевым URL для нового ответвления будет URL источника, базового для вашей рабочей копии. Вы должны изменить этот URL так, чтобы он указывал новый путь вашего ответвления/метки. Так, вместо

http://svn.collab.net/repos/ProjectName/trunk

вы можете использовать что-то вроде

http://svn.collab.net/repos/ProjectName/tags/Release_1.10

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

Там, где ответвления используются для обеспечения отдельных линий разработки, на некоторой стадии возникает необходимость произвести слияние сделанных в одном из ответвлений изменений со стволом, или наоборот, ствола с ответвлением. Cлияние всегда происходит в рабочей копии. Если вы желаете произвести слияние с ответвлением, у вас для этого ответвления должна быть извлечена рабочая копия, и мастер слияния необходимо вызывать из этой рабочей копии при помощи TortoiseSVN->Слить.

Ответвление и слияние может производиться разными способами (п.4.19-4.20).

Распределенные системы контроля версий (git, Mercurial, Bazaar).

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

Откатиться к начальному состоянию невозможно — значит потерять уже проведенную работу. Ну или, если совсем усложнить, завести отдельную копию проекта, в ней исправить ошибку (внести функционал), закоммитить, затем стереть копию, и вернуться к прежней работе. Кроме того, иногда требуется работать без доступа к центральному репозитарию (удаленная работа, поездка и т.д. и т.п.). Что делать? Лишаться всякой гибкости разработки и заливать монстроидальный коммит весом в неделю?

Итак, в чем заключается глобальное отличие git (и DVCS вообще) от централизованных аналогов?

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

Во вторых, операции ветвления и слияния веток (merging) ставятся во главу угла при работе программиста, и поэтому они очень легковесны.

Кстати говоря, привычных ревизий также не существует.

Итак, рассмотрим простейший случай: личный проект, в котором участвует единственное одно лицо — вы. Для создания нового репозитария достаточно просто зайти в папку проекта и набрать:

git init

Был создан пустой репозитарий — папка .git в корне проекта, в которой и будет собираться вся информация о дальнейшей работе (и никаких некрасивых .svn, разбросанных по дереву проекта!). Предположим, уже существует несколько файлов, и их требуется проиндексировать командой git add:

git add .

Внесем изменения в репозитарий:

git commit -m "Первоначальный коммит"

Готово! Имеется готовый репозитарий с единственной веткой. Допустим, потребовалось разработать какой-то новый функционал. Для этого создадим новую ветку:

git branch new-feature

И переключимся на нее (обратите внимание на отличие в терминологии по сравнению с SVN):

git checkout new-feature

Вносим необходимые изменения, после чего смотрим на них, индексируем и коммитимся:

git status

git add .

git commit -m "new feature added"

Теперь у нас есть две ветки, одна из которых (master) является условно (технически же ничем не отличается) основной. Переключаемся на нее и включаем изменения:

git checkout master

git merge new-feature

Легко и быстро, не находите? Веток может быть неограниченное количество, из них можно создавать патчи, определять diff с любым из совершенных коммитов.

Теперь предположим, что во время работы выясняется: нашелся небольшой баг, требующий срочного внимания. Есть два варианта действий в таком случае. Первый состоит из создания новой ветки, переключения в нее, слияния с основой… Второй — команда git stash. Она сохраняет все изменения по сравнению с последним коммитом во временной ветке и сбрасывает состояние кода до исходного:

git stash

Исправляем баг и накладываем поверх произведенные до того действия (проводим слияние с веткой stash):

git stash apply

Вот и все. Очень удобно. На самом деле таких «заначек» (stash) может быть сколько угодно; они просто нумеруются.

При такой работе появляется необычная гибкость; но среди всех этих веточек теряется понятие ревизии, характерное для линейных моделей разработки. Вместо этого каждый из коммитов (строго говоря, каждый из объектов в репозитарии) однозначно определяется хэшем. Естественно, это несколько неудобно для восприятия, поэтому разумно использовать механизм тэгов для того, чтобы выделять ключевые коммиты: git tag просто именует последний коммит; git tag -a также дает имя коммиту, и добавляет возможность оставить какие-либо комментарии (аннотацию). По этим тегам можно будет в дальнейшем обращаться к истории разработки.

Плюсы такой системы очевидны! Вы получаете возможность колдовать с кодом как душе угодно, а не как диктует система контроля версий: разрабатывать параллельно несколько «фишек» в собственных веточках, исправлять баги, чтобы затем все это дело сливать в единую кашу главной ветки. Замечательно быстро создаются, удаляются или копируются куда угодно папочки .git с репозитарием, не в пример SVN.