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

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

Почему Git?

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

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

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

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

Git через SVN

Есть ряд причин для выбора Git по сравнению с другой системой контроля версий, однако все зависит от вашей команды и настроек проекта. Чтобы помочь вам сделать правильный выбор, ниже мы сравниваем Git с Subversion (SVN) и объединяем некоторые поразительные отличия.

Распределенные рабочие процессы

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

  • Это не канонично - нет основной копии проекта, каждый пользователь хранит свою копию локально.
  • Общие операции (такие как фиксация, просмотр истории и возврат изменений) выполняются быстро, потому что нет необходимости связываться с центральным сервером.
  • Вместо этого общение необходимо только при изменении среди других сверстников.
  • Каждая рабочая копия эффективно работает как удаленная резервная копия базы кода и ее истории, обеспечивая естественную защиту от потери данных.
  • В распределенных системах контроля версий вы можете создать несколько «центральных» репозиториев.
  • В наличии имеются различные модели развития, такие как модель командира / лейтенанта, позволяющая эффективно делегировать актуальные разработки в более крупные проекты.
  • Для большинства операций подключение к Интернету не требуется.
  • Дополнительный набор операций «синхронизации» доступен для фиксации или получения изменений с удаленными репозиториями.

Хотя их очень мало, распределенные системы контроля версий также имеют некоторые недостатки. Здесь мы перечислили два основных:

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

Ветвление

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

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

Требуется меньше места

Меньшие требования Git к пространству основаны на размерах его репозитория и рабочего каталога, которые намного меньше, чем в SVN. Это происходит главным образом потому, что рабочий каталог SVN всегда содержит две копии каждого файла - одну для работы, а другую в «.svn /» для облегчения операций, таких как статус, сравнение и фиксация. С другой стороны, для рабочего каталога Git требуется только один небольшой индексный файл, содержащий около 100 байт данных на каждый отслеживаемый файл. Это может существенно повлиять на дисковое пространство, необходимое для проектов с большим количеством файлов.

SVN поверх Git

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

Единое хранилище

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

Контроль доступа

Единый центральный репозиторий в SVN позволяет пользователю определять элементы управления доступом для чтения и записи в одном месте и применять их ко всему проекту.

Двоичные файлы

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

Частичная оплата / требования к пропускной способности

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

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

Рекомендации по использованию Git

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

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

Сохраняйте последовательность в истории. При работе с ветвью и создании N коммитов рекомендуется объединить коммиты в одну перед объединением ветки с ее родительской. Это обеспечит последовательную и, следовательно, легко читаемую историю.

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

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

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

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

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

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

Заключительные мысли

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

Мартин - консультант по программному обеспечению в Accedia - болгарской технологической компании, специализирующейся на разработке приложений и ИТ-консалтинге. У него более 3 лет опыта решения задач в культуре, ориентированной на результат. Если вы хотите узнать больше, свяжитесь с нами по адресу [email protected].