Предыдущий ролик Следующий ролик  

Видео урок: О распределенной системе контроля версий

Git: обучение основам

В этом ролике я хочу пояснить, что обозначает распределенный контроль версий, так чтобы мы могли понять, почему это важная черта для Git. В предыдущем ролике мы рассмотрели историю систем контроля версий, мы говорили о SCSS, RCS, CVS и SVN, четырех наиболее популярных VCS прошлого. И все четыре используют центральную модель хранилища кода, то есть есть одно центральное место, где вы сохраняете основную версию кода, а когда вы работаете с кодом, вы проверяете копию из основного репозитория. вы работаете с ней, делая свои изменения, а затем вы добавляете эти изменения обратно в основной репозиторий. Другие пользователи также могут работать из этого репозитория, добавляя свои изменения. И это зависит полностью от нас, как от пользователей, отслеживать все, что происходит в этом центральном хранилище, чтобы убедиться, что мы можем скачать и обновить любые изменения, которые были сделаны другими людьми. Git не работает таким образом, Git - это распределенный контроль версий. Различные пользователи - или группы пользователей - поддерживают свои собственные репозитории вместо работы с центральным репозиторием. Все изменения сохраняются как набор изменений или патчей, и мы фокусируемся на отслеживании изменений, а не на версиях документа. Вы можете подумать, что разница невелика, ну, CVS и SVN тоже отслеживают изменения. Они отслеживают сделанные изменения от версии к версии каждого из различных файлов или различных состояний директории. Git не работает таким образом, Git в действительности фокусируется на наборе изменений, инкапсулируя набор изменений как дискретную единицу, а затем эти наборы изменений могут меняться между репозиториями. Мы не пытаемся идти в ногу с последней версией чего-то, а вопрос состоит в том, применяем мы или нет набор изменений? Итак, здесь нет основного репозитория, а есть множество работающих копий, каждая со своей комбинацией наборов изменений. Давайте я все вам покажу, чтобы было ясно. Давайте представим, что у нас есть изменения к одному документу как наборы A, B, C, D, E и F. Мы даем им произвольные имена, так что нам легко их увидеть. У нас есть, например, первый репозиторий, в котором находятся все эти шесть наборов изменений. У нас может быть репозиторий 2, в котором находятся только четыре изменения. Это не значит, что он хуже репозитория 1 или что ему нужны обновления, просто у него не такой же набор обновлений. У нас может быть репозиторий 3, у которого есть A, B, C и E, и репозиторий 4, у которого есть A, B, E и F. Ни один из них не является правильным, и ни один из них не является ложным. Ни один из них не является главным репозиторием, и другие типа как устарели или не синхронизированы с ним. Это просто разные хранилища с различными наборами изменений. Мы могли бы легко добавить набор изменений G в репозиторий 3, а затем мы могли бы поделить его с репозиторием 4 без необходимости вообще идти к центральному серверу. Например, тогда как с CVS и SVN вам необходимо было бы предоставить эти изменения центральному серверу, и тогда людям нужно было бы скачать эти изменения, чтобы обновить свои версии файлов. Теперь, по соглашению мы часто обозначаем репозиторий как основной репозиторий, но это не встроено в Git, не является частью Git архитектуры, это просто соглашение, и мы просто говорим - Ок, это главный репозиторий, и все будут отправлять ему свои изменения, мы попытаемся все быть синхронизированы с ним, если нужно. На самом деле у нас может быть три или четыре различных основных репозитория с разными версиями, разными особенностями, и мы могли бы отправлять им всем изменения, потом просто обменивая эти изменения между ними. Из-за своей распределенности у него есть множество преимуществ, это обозначает, что нет необходимости общаться с центральным сервером, и поэтому все происходит быстрее, и это значит, что для отправки изменений не требуется сетевой доступ, например, мы можем работать в самолете. И ничего не поломается. С CVS и SVN если что-то не так с центральным репозиторием, это может реально остановить всю работу для всех, кто работает удаленно от центрального репозитория. С Git у нас нет этой проблемы, любой может продолжить работу, у каждого есть свой собственный репозиторий, с которым он может работать, а не просто копия, которую все пытаются синхронизировать с центральным репозиторием. Он также поощряет участие в разветвлении проектов, а это действительно важно для сообщества, работающего с открытыми источниками. Поскольку разработчики могут работать независимо, они могут вносить изменения, фиксить баги, улучшать какие-то возможности, а затем отправлять их в проект для дальнейшего включения либо отклонения. И если вы решите, что вам не нравится способ, которым работает открытый проект, вы можете выложить его, отправить его в совершенно другом направлении и сказать - знаете что, я собираюсь красиво с этим порвать и сделать теперь мой репозиторий единственным, с которым я буду работать, все мои изменения я буду отправлять туда, и я все еще могу забирать наборы изменений из основного хранилища в мой проект, когда захочу. Но мне это и не нужно, я могу пойти своим путем. Это действительно становится мощной и гибкой возможностью, которая отлично подходит для сотрудничества между командами, особенно свободными группами удаленных разработчиков, как в мире опен сорса. Распределенный контроль версий является важной частью Git архитектуры, о которой вы должны помнить. Особенно, если у вас есть опыт работы с другими системами контроля версий как CVS или SVN. Далее мы более подробно поговорим о том, как Git отслеживает и делает слияние этих наборов изменений. Теперь же просто поймите, что нет центрального хранилища, с которым мы работаем, все репозитории Git считает одинаковыми, все дело в том, есть ли в репозитории набор изменений или нет.