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

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

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

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

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

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

И тогда удаленный сервер создает тот же самый бранч с теми же коммитами, с теми же самыми ID коммитов, и тогда другие люди получают возможность видеть наши коммиты. Одновременно Git также создает другой бранч на нашем локальном компьютере, обычно он называется origin, слэш, а затем имя бранча. Это вот такое соглашение, мы поговорим о том, как можно поменять имя, оно не обязательно должно быть origin, но сейчас мы поработаем именно с ним. Итак, origin/master - это бранч на локальном компьютере, который ссылается на удаленный сервер, и он всегда пытается быть синхронным с ним. Прямо сейчас кажется, что все три из них находятся в синхронном состоянии, но это не всегда так.

Мы продолжаем разработку, мы делаем коммиты в мастер-бранч, когда мы готовы поделиться этими коммитами, мы отправляем их на удаленный сервер, и Git также обращает внимание на изменение в бранче origin/master, это бранч, который пытается синхронизироваться с удаленным репозиторием. Когда другие люди отправляют изменения на удаленный сервер, нам нужно забрать эти изменения, и способ, которым мы это делаем, называется "извлечение" (fetch). То есть, мы извлекаем изменения, и в этот момент они попадают в наш бранч origin/master, таким образом, они синхронизированы. Извлечение, на самом деле, говорит Git синхронизировать origin/master с версией на удаленном сервере. но он не вносит изменения в основной бранч.

Теперь наш компьютер знает об этом изменении, оно существует у нас локально, и если мы, например, полетим на самолете, у нас будет копия этого коммита, коммита 923ea, но его не будет в нашем основном бранче, пока мы не сделаем слияние, тогда уже он будет внесен в основной бранч, и все снова будет синхронизировано. Это довольно упрощенный пример, потому что вы, наверное, заметили, что на моем компьютере есть много дублирования. Вы видите, что некоторые Git объекты дважды перечисляются на моем компьютере. На самом деле, Git их не сохраняет дважды. Git довольно умно поступает с этими объектами, потому что они абсолютно одинаковы.

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

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

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

Вы видите, что origin/master все еще включает в себя эти объекты, которые находятся в удаленном хранилище, они все еще синхронны, но в это время у меня появляется новый коммит ba8ce. Теперь наши два бранча уже не синхронны, мы должны сделать слияние, чтобы они снова были синхронными, и этот тот же самый процесс, который происходит со слиянием обычных бранчей. Origin/master - это просто бранч, так что мы можем сделать слияние, а затем отправить все на удаленный сервер, изменения из основного бранча будут отправлены в этот бранч, а затем отправлены на удаленный сервер.

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