Много есть различных статей на тему использования Version Control System или Revision Control System. И я решил немного написать о тех VCS с которыми имел дело.
Первая из них, и на мой взгляд наиболее юзабельная, для коллективной разработки Team Foundation System от Microsoft. Про то как устроена серверная часть знают далеко не все, и я не исключение. Думаю не стоит заострять на этом внимание рядовых разработчиков. Нам, разработчикам, интересен именно клиентский софт и интеграция с IDE. В случае с TFS клиенту предоставляются такие варианты: интеграция с Visual Studio, интеграция с контекстным меню Explorer-а, плагин для Eclipse, возможно еще что-то. Примерный перечень команд виден со скрина:
Типичный алгоритм работы:
1. "Get Latest Version", либо "Get Specific Version".
2. Делаем "Checkout for Edit...". Там выбираются файлы с которыми вы будете работать, можно их заблокировать для того, чтобы их никто больше не брал для редактирования (это делает редко). В IDE всегда есть возможность посмотреть кто на данный момент с какими файлами работает. И всегда есть возможность сравнить вашу версию файлов с версией любой ревизии. Ревизии идут по порядку.
3. Меняем код.
4. Делаем "Check In Pending Changes...", если он активный. И скорей всего вас попросят сделать "Get Latest Version", либо он сам приедет с сервера, либо вам придётся это сделать, чтобы продолжить работу.
5. При возникновении конфликтов, а конфликты возникают далеко не часто. Обычно они разрешаются системой автоматически. При checkout-е система запоминает, когда вы взяли файлы, и на основании этого понимает какие изменения произошли позже, какие раньше. Итак, при возникновении конфликтов, вы можете разрешить их в любой удобной для вас программе, если вас не устраивает встроенный в IDE merge/compare редактор. Итогом разрешённого конфликта будет сохранение файла под его естественным именем.
6. Делаем "Check In Pending Changes...".
Вторая VCS хорошо известна всем. И интеграция с ней есть везде. SVN с перечнем команд:
Типичный алгоритм работы:
1. Checkout - просто скачивается весь или часть репозитория. Либо Update, в случае если он у вас уже есть и вы его давненько скачали. Ревизии идут по порядку.
2. Меняем код.
3. В эклипсе очень удобно ткнуть Synchronize. При этом у вас появится окно, где можно будет увидеть существуют ли какие-либо конфликты с тем что находится на сервере. Если такие имеются, то вы можете скажем откатить изменения на каких-либо поменяных вами локально файлах.
4. Делается Commit, который скидывает всё что вы наделали на сервер.
5. При возникновении конфликтов происходит/делается Update, и вы можете их разрешить опять же в различных merge/compare тулзах, если вас не устраивают встроенные средства IDE. Результатом разрешения конфликта становится файл, под своим естественным названием
помеченный как merged.
6. Делается Commit, который скидывает всё что вы наделали на сервер.
Третья система контроля версий Git. Интеграция IDE с ней появилась относительно недавно, и везде очень "по разному". От первых двух она отличается тем, что вам сразу без вариантов предлагают двухуровневую схему наката изменений. Кто-то считает, что в этом заключается одно из преимуществ git-а перед остальными. Вы можете обходиться вообще без сервера. Локальная копия репозитория может жить автономно. Скриншот не вмещает всего многообразия операций:
Нетипичный для Git, но типичный для вышеупомянутых VCS режим работы:
1. Делается Clone репозитория. Далее делается Checkout интересующей ветки. Обычно это master - ветка (origin/master). Ревизий как таковых нет, есть commit-ы.
2. Меняем код.
3. Делаем Commit, при этом изменения улетают в локальный репозиторий.
4. Делаем Push, чтобы изменения локальной ветки master улетели на сервер.
5. Возникли конфликты! Делаем Pull - изменения с сервера прилетают в локальный репозиторий. Тут-то мы их и мерджим. Результатом работы merge является файл под своим именем, помеченный как stage.
6. Как финальная стадия merge-операции делается Commit. Или Commit & Push.
7. Вобщем вы решили конфликты у себя локально, а теперь будьте любезны скинуть всё это добро на сервер. Делаем Push.
Более рассказывать про иные VCS я не сподоблюсь. Как видно из этого описания, работа с SVN и с TFS происходит примерно одинаково. За исключением того, что SVN всё-таки более ущербен, хотя-бы потому что у него в каждой папке вашего "родного" содержимого спрятаны свои служебные каталоги. УЖОСНАХ. Ну а последняя VCS заставляет разработчика быть более квалифицированный в процессах слияния. Ну кому нужны проблемы с разрешением конфликтов и осознавание того, в какой ветке вам нужно работать?? Да никому. Написал код, слил на сервер - ура, свободен. А в Git люди тащутся от того как они эти изменения вносят. Это на самом деле работа релиз-менеджера. Релизы разделены по отдельным веткам. И он решает нужно ли вносить ваши изменения в ту или иную ветку. Ну а для вас, как разработчика, существует одна текущая, и она же последняя ветка.
С нетерпением ждите следующего поста, про Git. Там я опишу, как можно, всё-таки не поседев, уживаться с этим зверем.
