Распределенная система контроля версий Git

О Git

Git - это бесплатная распределенная система контроля версий с открытым исходным кодом, предназначенная для быстрой и эффективной работы с любыми проектами - от небольших до очень крупных. Git прост в освоении и занимает мало места при молниеносной производительности. Он превосходит такие инструменты SCM, как Subversion, CVS, Perforce и ClearCase, благодаря таким возможностям, как дешевое локальное ветвление, удобные области хранения и множество рабочих процессов.

Ветвление и слияние

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

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

Это означает, что вы можете делать такие вещи, как:

• Беспрепятственное переключение контекста. Создайте ответвление, чтобы опробовать идею, зафиксируйте несколько раз, переключитесь обратно на то место, откуда вы сделали ответвление, примените исправление, переключитесь обратно на то место, где вы экспериментируете, и объедините его.

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

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

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

Ветви

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

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

Маленький и быстрый

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

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

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

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

Все это время указано в секундах.

Распределенный

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

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

Любой рабочий процесс

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

Рабочий процесс в стиле Subversion

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

Рабочий процесс менеджера интеграции

Другой распространенный рабочий процесс Git включает в себя менеджера интеграции - одного человека, который коммитит в "благословенный" репозиторий. Затем несколько разработчиков клонируют из этого репозитория, делают push в свои собственные независимые репозитории и просят интегратора притянуть их изменения. Такая модель разработки часто встречается в репозиториях с открытым исходным кодом или GitHub.

Рабочий процесс диктатора и лейтенантов

Для более масштабных проектов часто эффективен рабочий процесс разработки, подобный тому, который используется в ядре Linux. В этой модели некоторые люди (лейтенанты) отвечают за определенную подсистему проекта, и они объединяют все изменения, связанные с этой подсистемой. Другой интегратор (диктатор) может получать изменения только от своих лейтенантов, а затем отправлять их в "благословенный" репозиторий, из которого потом все снова клонируют.

Обеспечение целостности данных

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

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

Большинство централизованных систем контроля версий по умолчанию не обеспечивают такой целостности. Область хранения

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

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

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

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