Git svn что это

В чем различия между Git и SVN?

Вопрос, собственно выбора. Чем Git лучше или хуже SVN? Почему чаще от разработчиков я слышу именно про Git и его удобства, чем про SVN, хотя как по мне, все что слышал можно делать и в SVN. Причём для обоих вариантов есть удобный Tortoise, что сводит общение с репозиториями практически на один уровень. Может просто что-то плохо рекламируют, а разницы вообще нет?

Отслеживать
user177221
задан 17 сен 2013 в 15:11
pincher1519 pincher1519
2,528 4 4 золотых знака 35 35 серебряных знаков 56 56 бронзовых знаков

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

17 сен 2013 в 15:20
@pirj Расскажите, пожалуйста, если у вас найдется минутка, почему вы пришли к такому выводу.
17 сен 2013 в 15:26

>Если вы работали с тем или другим, то вы знаете, чем одно лучше другого @pirj мне кажется, что ТС задал этот вопрос именно потому, что он не работал с тем и другим. И да, вы забыли аргументировать ваше бесспорно взешенное мнение

17 сен 2013 в 15:52

да ладно, вы сейчас человека на svn уговорите, аргументы в инете и их много. я бы ещё понял если бы выбор между git и mercurial был. а svn это кошмар. не знаю как там разработчикам, я его админил.

17 сен 2013 в 16:05
Еще есть такая штука как Mercurial — тоже довольно таки удобная
17 сен 2013 в 23:04

5 ответов 5

Сортировка: Сброс на вариант по умолчанию

GIT распределяется, а SVN — нет. Другими словами, если есть несколько разработчиков работающих с репозиторием у каждого на локальной машине будет ПОЛНАЯ копия этого репозитория. Разумеется есть и где-то и центральная машина, с которой можно клонировать репозиторий. Это напоминает SVN. Основной плюс в том, что если вдруг у вас нет доступа к интернету, сохраняется возможность работать с репозиторием. Потом только один раз сделать синхронизацию и все остальные разработчики получат поолную историю.
GIT сохраняет метаданные изменений, а SVN целые файлы. Это экономит место и время.
Система создания branches, versions и прочее в GIT и SVN отличаются значительно. В GIT проще переключатся с ветки на ветку, делать merge между ними. В общем GIT я нахожу немного проще и удобнее, но бывают конечно иногда сложности. Но где их не бывает?

Разумеется есть гораздо больше отличий, но я перечислил те, которые чаще всего встречаются при работе с репозиториями и на МОЙ взгляд наиболее важные.

Отслеживать
ответ дан 17 сен 2013 в 15:49
3,521 12 12 серебряных знаков 20 20 бронзовых знаков

— У вас часто не бывает доступа к интернету, когда вы работаете? — Это, естественно, неправда. И Subversion, и Git хранят дельты изменений. См., например, git-scm.com/book/ch9-4.html и stackoverflow.com/questions/127692/…

17 сен 2013 в 15:56

ну пусть не часто нет интернета, но не будете же Вы отрицать, что наличие полной копии репозитория на локальном компьютере это не отличие? Я просто привел пример, когда это может быть полезно. На счет файлов — спасибо, просветился.

17 сен 2013 в 15:59

Для меня тот факт, что с git можно работать локально — большой плюс. К примеру, можно поработать в самолете. Или к примеру, начал делать свой маленький проектик — тут же добавил в git. Если что то не так — удалил. Еще большой плюс локальности — для больших команд. Пришел новый разработчик — давать ему доступ на коммиты сразу — глупо (если это только не Кармак или ван Россум). А так — коммитить он может себе, может запушить это кому-то из разработчиков ( да, я знаю, в свн есть диффы. )

18 сен 2013 в 11:36

Новички они такие. Чуть не досмотрел — а он уже пол репозитория переработал. > однако хранить гигабайты кода на локальной машине — зачем? а никто не заставляет гигабайты хранить. можно удалять у себя ненужные ветки, делать git gc. Но в случае, если внешний репозитарий испортился, его можно восстановить из локальных копий. Только не говорите о бэкапах — иногда средства бекапа бывают такое выдают.

how to: Как и зачем работать с svn через git

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

SVN

Subversion — это централизованная система контроля версий. Это главный ее минус и главный ее плюс 🙂

Плюс в том, что централизация дает возможность, например, нумеровать коммиты, т.к. их порядок известен.
Так же она минимизирует конфликты (хотя об этом можно и поспорить), т.к. текущее состояние репозитория одно и оно всем известно.
В svn можно хранить несколько проектов в одном репозитории. Вообще интефрейс репозитория в svn очень похож на файловую систему, что обеспечивает минимальный порог вхождения для тех, кто никогда не работал с системами контроля версий.

Главный минус — это merge… Те, кто часто делает мерж средствами svn, понимает о чем я.
Это медленно (даже меееееееедлееенно), требует постоянного соединения с репозиторием, а еще эти svn-properties, которые мешают читать diff.

Казалось бы — решение лежит на поверхности, надо просто сменить систему контроля версий. В нашем же случае нельзя просто так взять и перейти на git.

Причин тому несколько, и все они обусловлены наследием. Если бы мы начинали разработку сейчас, то скорей бы всего выбрали git. У нас репозиторию уже около шести лет, за это время мы создали в нем 129 проектов, а число ревизий перевалило за 88 000.
Мы используем trac в качестве багтрекера. В нем сейчас более 10 тыс тикетов. Во многих есть ссылки на коммиты, подтверждающие исправления. Это богатое наследие терять не хочется.
Так же у svn есть плюс — все проекты лежат в одном репозитории. Trac думает, что проект у нас один, что сильно облегчает работу с ним.
Другими словами, отказ от svn для нас слишком затратен, но мержи.

Решение

Устанавливаем git и git-svn. Метод установки зависит от вашей операционной системы. В моем случае сводится к простому набору команд:

apt-get update && apt-get install subversion git git-svn

[user] email = e.kokovikhin@co.wapstart.ru name = Evgeniy V. Kokovikhin [core] editor = vim [alias] co = checkout br = branch ci = commit st = status di = diff --color

cd /var/www/project.wapstart/ mkdir project && cd project # создали папку для проекта git svn init --stdlayout https:/path.to.your.svn.server.ru/project # создаст пустой git репозиторий git svn fetch

Последняя команда займет ощутимое время. На нашем репозитории — часа 4.
—stdlayout как бы говорит нам, что расположение проекта у нас стандартное:

project ├── trunk ├── branches │ ├── dovgFeature │ └── dovgAnotheFeature └── tags ├── 3.0.1 └── 3.0.2

Транк теперь называется master, все остальные бранчи именованы как обычно.
Работа с бранчами:

 git branch -r # список бранчей git checkout -b dovgBranch dovgBranch # создать новый локальный бранч dovgBranch из удаленного бранча dovgBranch git branch # — список локальных бранчей и отметка текущего

dovg@marvin ~/job/oemdesign/www/plus1.wapstart.loc/plus1 $ git branch dovgUnique experimental * master moderation production referals targetingCountry uniqueCookie uniqueSession ---------

И как теперь с этим работать?

 git svn rebase # обновить текущую ветку (на самом деле не совсем так) git svn fetch # обновить весь репозиторий git svn dcommit # закоммитить локальные коммиты в svn репозиторий git svn branch # создать бранч :) больше информации в git svn help branch git svn info # информация о ветке svn, в которую смотрит локальная ветка

git merge --log master # смержит все изменения с красивым логом из главной ветки в текущий бранч.

Для мержа в master (trunk)

git checkout master git merge --no-ff # отмена fast forward merge

git diff — аналог git commit — закоммитить локально «подготовленный» файл git commit -a — закоммитить локально все файлы, которые уже под контролем, но в них были изменения git add — подготовить файл к коммиту. Тут есть отличие от svn. В svn надо добавлять только новые файлы, а в git все измененнные, если вы не пользуетесь git commit -a git reset --hard — прибить все локальные изменения.

Сделать бранч и переключится в него: git svn branch ticket-666 && git svn fetch && git co -b ticket-666 ticket-666
Перенести бранч в мастер: git co ticket-666 && git merge —log —no-ff master && git svn dcommit && git co master && git merge —log —no-ff ticket-666 && git svn dcommit
Сдать бранч в тест (обновить из мастера и закомитить): git co ticket-666 && git merge —log —no-ff master && git svn dcommit
Обновлять периодически репозиторий: git svn fetch

Вместо заключения

Долгое время эта статья провисела во внутренней вики Wapstart. Мне показалось, что она может быть полезна сообществу. Результат перед вами. 😉

Системы контроля версий: Git, SVN, Mercurial для менеджеров

Задача проектного менеджера и коммерческой разработки как таковой — ставить конкретные цели и отслеживать этапы выполнения работ.

Для этого в производственный процесс принято внедрять ежедневные митинги, таск трекеры и системы контроля версий (СКВ или VCS — Version Control System), которые мы рассматриваем как инструменты для управления проектами.

Выбор СКВ лежит на плечах технического директора, тимлидов или воли случая (“так исторически сложилось”). Вопросы о преимуществах или недостатках конкретных систем вызывают священные войны в среде разработчиков, однако, наc они итересуют только в контексте организации работы над проектом.

Все системы контроля версий по сути решают 4 задачи

Доступ к коду. Исходники кода хранятся в удаленном репозитории (хранилище данных), куда обращаются разработчики, чтобы забрать актуальную версию файлов или внести изменения. Так выстраивается командная разработка.

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

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

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

Организация процесса разработки

Вам, как менеджеру проекта, стоит обратить внимание:

Принят ли у разработчиков единый шаблон оформления комментариев к коммитам (commit message), из которых понятно, что делает коммит и зачем.

Настроена ли привязка коммитов к конкретным задачам из таск трекера (traceability) для трассировки бизнес требований.
В Mercurial это работает из коробки, а вот, например, в Git это обычно решают с помощью хука, который не дает ничего закоммитить без метки таска, а-ля “PROJECT-JIRA_ISSUE_NUMBER”

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

Последний вопрос не актуален, если разработчики используют на проекте SVN, так как это централизованная СКВ и весь код хранится на сервере.

Распределенные и централизованные подходы к хранению кода

Git и Mercurial — распределенные системы, SVN — централизованная.

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

При этом Git, в отличие от Mercurial, работает не только с локальными коммитами, но и с локальными ветками, которые можно вовсе не заливать в удаленный репозиторий.

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

C этой точки зрения, SVN лучше вписывается в модель коммерческой разработки, где мы ежедневно контролируем объем и качество выполненной работы.

При использовании Git или Mercurial проектному менеджеру необходимо установить правило ежедневных коммитов для разработчиков, это особенно критично для удаленных команд или аутсорсеров.

Как менеджеру освоить базовые функции Git

Вероятность столкнуться с использованием гита на проекте 90%, поэтому небольшая рекомендация для тех, кто собрался его изучить.

Короткий видеокурс Geekbrains для старта за 2 часа.
Официальная документация для дотошных.

Программное окружение:

На Mac Git по умолчанию вшит в штатную консоль. На Windows первым делом скачайте и установите сам Git.

С гитом работают через консоль или графический интерфейс (GUI).

Графический интерфейс SourceTree для работы менеджера с Git

Для задач IT-менеджера рациональнее использовать графический клиент. Лично я использую SourceTree, хотя не всем нравится продукция Atlassian.

Выберите клиент по вкусу вот тут.

Вперед к первому $ git clone!

Подготовка к миграции из SVN в Git

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

В этой статье описываются некоторые серьезные изменения, с которыми вы столкнетесь при переводе команды из SVN в Git. В процессе миграции крайне важно помнить о том, что Git — это не SVN. Чтобы реализовать весь потенциал Git, постарайтесь по-новому подойти к управлению версиями.

Для администраторов

С учетом размера команды внедрение Git может занять от пары дней до нескольких месяцев. В этом разделе рассматриваются некоторые основные проблемы, с которыми сталкиваются технические менеджеры при обучении сотрудников работе с Git и при переносе репозиториев из SVN в Git.

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

Раньше систему Git считали сложной для освоения. Однако специалисты по сопровождению Git постоянно выпускают новые улучшения, например разумные умолчания и контекстные справочные сообщения, которые упрощают адаптацию.

Atlassian предлагает полный набор учебных руководств по Git для самостоятельного изучения, а также вебинары и учебные занятия в режиме реального времени. В совокупности они охватывают все варианты обучения, необходимые команде для начала работы с Git. Для начала ознакомьтесь со списком основных команд Git, которые помогут вам приступить к работе:

базы данных

Связанные материалы

Перемещение полного репозитория Git

СМ. РЕШЕНИЕ

Изучите Git с помощью Bitbucket Cloud

Задача в Git

Заметки

Команды Git

Указать имя автора и адрес электронной почты, которые будут использоваться в коммитах. Обратите внимание, что Git удаляет из user.name некоторые символы, например точки в конце.

git config —global user.name «Sam Smith»git config —global user.email sam@example.com

Создать рабочую копию локального репозитория:

git clone /путь/к/репозиторию

Если сервер удаленный, использовать следующую команду:

git clone username@host:/путь/к/репозиторию

Добавить один или несколько файлов в раздел проиндексированных файлов (индекс):

Сделать коммит изменений в расположение HEAD (но не в удаленный репозиторий):

git commit -m «Комментарий к коммиту»

Сделать коммит файлов, которые вы добавили командой git add, а также файлов, которые вы с тех пор изменили:

Отправить изменения в главную ветку удаленного репозитория:

git push origin main

Вывести список всех файлов, которые вы изменили, а также файлов, которые еще нужно добавить или для которых нужно сделать коммит:

Если вы еще не подключили локальный репозиторий к удаленному серверу, добавьте сервер, чтобы можно было отправлять туда изменения:

git remote add origin

Вывести список всех настроенных на данный момент удаленных репозиториев:

Создать новую ветку и переключиться на нее:

Переключиться с одной ветки на другую:

Вывести список всех веток в репозитории с указанием текущей ветки:

Удалить функциональную ветку:

Отправить ветку в удаленный репозиторий, чтобы другие разработчики могли с ней работать:

git push origin

Отправить все ветки в удаленный репозиторий:

git push —all origin

Удалить ветку из удаленного репозитория:

git push origin :

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

Выполнить слияние ветки с активной веткой:

Просмотреть все конфликты слияния:Просмотреть конфликты с базовым файлом:Предварительно просмотреть изменения перед слиянием:

git diff git diff —base git diff

Устранить все конфликты вручную и пометить измененный файл:

Для пометки существенных наборов изменений, таких как релизы, можно использовать теги:

Идентификатор коммита — это начальные символы идентификатора набора изменений (не более 10). Он должен быть уникальным. Получить идентификатор:

Отправить все теги в удаленный репозиторий:

git push —tags origin

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

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

git fetch origingit reset —hard origin/main

Выполнить поиск «foo()» в рабочем каталоге:

Инструменты миграции Git

Есть множество инструментов, которые помогут вам перенести существующие проекты из SVN в Git. Но прежде чем выбирать между ними, решите, как будете переносить код. Возможны следующие варианты:

Перенести всю базу кода в Git и полностью отказаться от использования SVN.
Не переносить существующие проекты в Git, но использовать Git для всех новых проектов.
Перенести некоторые проекты в Git и продолжить работу над остальными проектами в SVN.
Использовать SVN и Git одновременно для одних и тех же проектов.

Полный переход в Git упрощает процесс разработки, поэтому такой вариант является предпочтительным. Однако он не всегда подходит крупным компаниям с десятками команд разработчиков и сотнями проектов. Для них гибридный подход будет более безопасным решением.

Выбор инструментов миграции во многом зависит от того, какую из указанных стратегий вы предпочтете. Ниже представлено несколько наиболее популярных инструментов миграции из SVN в Git.

Скрипты миграции Atlassian

Если вы хотите быстро перейти в Git, вам подойдут скрипты миграции Atlassian. В этих скриптах есть все необходимые инструменты для надежного преобразования существующих репозиториев SVN в репозитории Git. Полученная собственная история Git поможет избежать проблем совместимости SVN и Git после перехода.

Мы подготовили полное пошаговое техническое руководство по использованию этих скриптов для преобразования всей базы кода в набор репозиториев Git. В этом руководстве подробно описывается каждый шаг — от извлечения из SVN информации об авторе до реорганизации нестандартных структур репозиториев SVN.

Плагин SVN Mirror for Stash (ныне Bitbucket)

SVN Mirror для StashSVN Mirror для Stash — это плагин Bitbucket, позволяющий без труда обслуживать гибридную базу кода, с которой можно работать в SVN и Git. В отличие от скриптов миграции Atlassian, с плагином SVN Mirror для Stash системы Git и SVN можно использовать вместе на любом этапе проекта.

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

Что такое Git-SVN?

Инструмент Git-SVN — это интерфейс между локальным репозиторием Git и удаленным репозиторием SVN. Git-SVN позволяет разработчикам писать код и создавать коммиты локально с помощью Git, а затем отправлять их в центральный репозиторий SVN в качестве коммитов SVN. Этот инструмент представляет собой временное решение, однако он может принести пользу, пока команда еще не приняла окончательное решение о переходе из SVN в Git.

Git-SVN подойдет, если вы не уверены насчет перехода в Git и хотите, чтобы некоторые разработчики могли изучить команды Git, не прибегая к полноценной миграции. Эта утилита также оптимальна для этапа обучения: коллектив может постепенно выполнять переход, использовать локальные команды Git и пока не задумываться о процессах совместной работы.

Обратите внимание, что работа с git-svn — это лишь один из этапов миграции. Этот инструмент опирается на SVN для работы c серверной частью и не позволяет использовать более мощные возможности Git, такие как ветвление или расширенные процессы совместной работы.

Стратегии развертывания

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

Внешние консультанты по Git

Консультанты по Git могут провести миграцию целиком за символическую плату. Преимущество этой стратегии в том, что ваша команда получит оптимальный рабочий процесс Git без каких-либо затрат времени с вашей стороны. Кроме того, разработчики смогут использовать опыт экспертов во время изучения Git. Консультантами по Git могут выступить партнеры Atlassian, поскольку они хорошо осведомлены по вопросам миграции из SVN в Git.

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

Внутренние сторонники Git

Сторонник Git — это разработчик в вашей компании, которому не терпится начать работу с Git. Услуги сторонника Git будут полезны компаниям с сильной культурой разработки и увлеченными программистами, которым нравится быть первопроходцами. Пусть один из инженеров станет экспертом по Git. Так он сможет спроектировать рабочий процесс Git с учетом потребностей компании и возьмет на себя обязанности внутреннего консультанта, когда потребуется перевести в Git остальных участников команды.

Преимущество этой стратегии по сравнению с привлечением внешнего консультанта заключается в том, что опыт работы с Git сохраняется внутри компании. Однако для обучения сторонника Git потребуется больше времени. Кроме того, существует риск, что он выберет неподходящий рабочий процесс Git или неправильно его реализует.

Пилотные команды

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

Преимуществом этой стратегии является участие всей команды. Кроме того, вы с меньшей вероятностью ошибетесь при выборе подходящего рабочего процесса, так как при проектировании нового процесса разработки предложения поступают от всех участников. То есть недостающие элементы будут обнаружены раньше, чем в случае, когда консультант или сторонник Git самостоятельно разрабатывают новый рабочий процесс.

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

Безопасность и права доступа

Контроль доступа — это один из аспектов Git, где требуется кардинально переосмыслить управление базой кода.

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

Это означает, что вам нужно разделить крупный монолитный репозиторий SVN на несколько небольших репозиториев Git. Нам в Atlassian тоже пришлось этим заниматься, когда наша команда разработчиков Jira переходила в Git. Раньше все наши плагины Jira хранились в одном репозитории SVN, а после миграции каждый плагин оказался в собственном репозитории.

Напомним, что система Git была разработана для безопасной интеграции кода от тысяч независимых разработчиков Linux, поэтому в ней можно тонко настроить контроль доступа, нужный команде. Однако для этого, возможно, придется по-новому взглянуть на цикл сборки.

Если вы беспокоитесь о сопровождении зависимостей в новом наборе репозиториев Git, вам может пригодиться уровень управления зависимостями в сочетании с Git. Уровень управления зависимостями поможет сократить время сборки, поскольку по мере роста проекта вам потребуется так называемое «кэширование» для ускорения сборки. Список рекомендуемых инструментов для уровня управления зависимостями с учетом стека технологий приводится в полезной статье «Git и зависимости проекта».

Для разработчиков

Репозиторий для каждого разработчика

Самое большое изменение, к которому вам как разработчику нужно приспособиться, — это распределенная природа Git. Вместо одного центрального репозитория у каждого разработчика есть полноценная собственная копия. Это кардинально меняет подход к совместной работе с коллегами-программистами.

Вместо того чтобы получить репозиторий SVN командой svn checkout и создать его рабочую копию, вы клонируете весь репозиторий Git на локальную машину командой git clone.

Совместная работа происходит путем перемещения веток между репозиториями с помощью команд git push, git fetch и git pull. В Git разработчики обычно делятся ветками, но это можно делать и на уровне коммитов, как в SVN. Однако в Git коммит представляет собой полное состояние всего проекта, а не изменения файла. Ветки можно использовать как в Git, так и в SVN, но важное различие заключается в том, что в Git можно выполнять локальные коммиты, не делясь своей работой. Это позволяет разработчикам свободно экспериментировать и более эффективно действовать в автономном режиме, а также ускоряет работу практически всех команд, задействованных в управлении версиями.

Однако важно понимать, что удаленный репозиторий не ссылается на чей-то чужой репозиторий напрямую. Это просто закладка, которую вы можете использовать, чтобы не вводить заново полный URL-адрес при каждом обращении к удаленному репозиторию. Пока вы явно не получите ветку из удаленного репозитория или не отправите ее туда, вы будете работать в изолированной среде.

Другое важное изменение для пользователей SVN — это «локальные» и «удаленные» репозитории. Локальные репозитории находятся на локальном компьютере, а все остальные называются удаленными. Последний нужен прежде всего затем, чтобы сделать ваш код доступным для остальных участников команды, поэтому там не ведется активная разработка. Локальный репозиторий находится на вашей локальной машине, где вы и создаете ПО.

Не бойтесь ветвления или слияния

В рамках SVN вы редактируете файлы в своей рабочей копии, а затем выполняете команду svn commit, чтобы отправить код в центральный репозиторий. После этого остальные разработчики могут перенести изменения в свои рабочие копии командой svn update. Ветки в SVN обычно создают для больших и долгосрочных частей проекта, потому что слияние сопряжено с риском и может навредить проекту.

Базовый процесс разработки в Git сильно отличается. Вместо привязки к одному направлению разработки, например к магистральному, процесс вращается вокруг ветвлений и слияний.

Начиная работу в Git, вы создаете новую ветку и переключаетесь на нее с помощью команды git checkout -b. Таким образом вы получите отдельное направление разработки, где сможете писать код, не беспокоясь о том, что ваша работа помешает другим участникам команды. Если вы непоправимо испортите код, можно будет просто удалить ветку командой git branch -d. Написав какой-либо полезный код, вы создадите запрос pull и объедините этот код с основной веткой.

Возможные варианты рабочих процессов Git

При выборе рабочего процесса Git важно учитывать потребности команды. Простой рабочий процесс может повысить скорость и гибкость разработки, а более сложный укрепит согласованность и контроль над текущей работой. Перечисленные ниже общие подходы можно адаптировать и сочетать с учетом потребностей и ролей в команде. Так, основной разработчик может взаимодействовать с функциональными ветками, в то время как подрядчик будет работать с форком.

Централизованный рабочий процесс очень похож на обычные процессы SVN, поэтому вы можете начать с него.
Рабочий процесс с функциональными ветками развивает эту идею: с его помощью разработчики могут изолировать текущую работу и защитить важные общие ветки. Кроме того, функциональные ветки создают основу для управления изменениями с помощью запросов pull.
Рабочий процесс Git-flow — это более формализованное и структурированное расширение процесса с функциональными ветками, поэтому он идеально подходит для больших команд с четкими циклами релизов.
И наконец, если вам нужна максимальная изоляция и контроль над изменениями или если в один репозиторий поступает код от нескольких разработчиков, попробуйте рабочий процесс с форками.

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

Заключение

Переход команды в Git может отнимать много времени и сил, однако его можно облегчить. В этой статье были рассмотрены некоторые распространенные варианты переноса существующей базы кода, развертывания Git в командах разработчиков, а также решения вопросов безопасности и прав доступа. Кроме того, мы рассказали о самых серьезных проблемах, с которыми могут столкнуться разработчики в процессе миграции и к которым они должны быть готовы.

Надеемся, теперь у вас есть прочная основа для внедрения распределенной разработки в своей компании, независимо от ее размера и текущих методов разработки.