Вход:  Пароль:  
FreeSource: RuslanHihin/gitusermanual/Chapter1 ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |

Глава 1. Репозитории и ветки


Оглавление документа Репозитории и ветки


1. Как получить git репозиторий

Будет полезно иметь git хранилище для экспериментов, пока вы читаете это руководство.


Лучший способ получить его с помощью команды git-clone(1), которая загрузит копию существующего репозитория. Если у Вы ещё не сообразили как это сделать, приведу несколько интересных примеров:


# взять сам git (примерно. 10MB закачки):
$ git clone git://git.kernel.org/pub/scm/git/git.git
# Ядро linux (примерно. 150MB закачки):
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

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


Команда clone создаёт новый каталог с именем проекта ( “git” или “linux-2.6” в приведённых выше примерах выше).


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

2. Как проверить различные версии проекта

Git это наилучший инструмент для хранении истории коллекции файлов.
Он хранит историю в виде сжатой коллекции взаимосвязанных отпечатков (снапшотов) содержимого проекта. В git каждая такая версия называется коммит.


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


Один Git репозиторий может отслеживать развитие в нескольких ветках.
Это позволяет сохранять список основных вершин (head) которые ссылаются на последние коммиты каждой ветки; команда git-branch показывает список вершин веток:

$ git branch
* master

Свежие склонированные репозитории содержат одну вершину ветки, по умолчанию имеющую название “master”, и стартовый рабочий каталог в соответствии с вершиной ветки master.


Большинство проектов также используют теги.


Тэги, подобно вершинам, являются ссылками в истории проекта, и могут быть перечислены командой git-tag(1):


$ git tag -l
v2.6.11
v2.6.11-tree
v2.6.12
v2.6.12-rc2
v2.6.12-rc3
v2.6.12-rc4
v2.6.12-rc5
v2.6.12-rc6
v2.6.13
...

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


Создать новую вершину ветки указывающую на одну из этих версий и проверить её можно с с помощью git checkout :

$ git checkout -b new v2.6.13

Рабочий каталог теперь отражает то содержимое проекта которое было при установке тега v2.6.13, а git-branch(1) показывает две ветви, причём звёздочкой помечена ветка указанная в команде git checkout :

$ git branch
master
* new 

Если вы решите, что вы хотите увидеть версию 2.6.17, вы можете изменить текущую ветку на точку v2.6.17 вместо текущей

$ git reset --hard v2.6.17

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

3. Понятие истории

3.1. Понятие истории: Коммиты

Каждое изменение в истории проекта представлено в виде фиксации (коммита).
Команда git-show(1) показывает самые последние коммиты текущей ветки:


$ git show
commit 17cf781661e6d38f737f15f53ab552f1e95960d7
Author: Linus Torvalds <torvalds@ppc970.osdl.org.(none)>
Date: Tue Apr 19 14:11:06 2005 -0700
Remove duplicate getenv(DB_ENVIRONMENT) call


Noted by Tony Luck.

diff --git a/init-db.c b/init-db.c
index 65898fa..b002dc6 100644


a/init-db.c
+++ b/init-db.c
@@ -7,7 +7,7 @@


int main(int argc, char **argv)
{

– char *sha1_dir = getenv(DB_ENVIRONMENT), *path;
+ char *sha1_dir, *path;

int len, i;


if (mkdir(«.git», 0755) < 0) {

Как вы можете увидеть, в коммите указатся кто сделал последние изменений, что сделал и почему.


Каждый коммит имеет 40-значный шестнадцатеричный идентификатор, который иногда называются «именем объекта» или «SHA1 идентификатором», и показывается в первой строке вывода “git show”.


Обычно, вы можете, ссылаться на коммит через короткое имя, такое как тег или имя ветви, но и имя образуемое SHA1 идентификатором часто тоже бывает полезным.


Самое главное в нём, что это уникальное имя для этого коммита: так, если вы скажите кому-нибудь другому название объекта (например, в электронной почте), то вам гарантируется, что это имя будет относиться к тому же коммиту что и в у вас (предполагается, что этот коммит есть у всех).
Это имя объекта вычисляется как хэш его содержимого коммита, и вам гарантируется, что содержимое коммита не может изменится без изменения его имени.


Фактически в Главе 7 «Концепция Git» мы увидим, что всё хранящиеся в истории git, включая файлы данных и содержимое каталога, хранится в объектах с именем которого является хэш его содержимого.

3.2. Понятие истории: Коммиты, родители и доступность

Каждый коммит (за исключением самого первого коммита в проекте) имеет родительские коммит, которые показывает, что произошло до этого коммита.
После цепочки родителей, в конечном итоге мы перейдём обратно в начальное состояние проекта.
Тем не менее, коммиты не образуют простой список; git позволяет разделять линии разработки, а затем объединять их снова, и точки, где два направления разработки объединяются в одно называются «слиянием» (merge).


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


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


Далее, мы говорим, что коммит Х «доступен» от коммита Y, если коммит Х предок коммита Y. Эквивалентно, можно сказать, что Y является потомком X, или что существует цепь родства (родителей), идущая от коммита Y до коммита X.

3.3. Понятие истории: Диаграммы истории

Мы будем иногда представлять git историю с помощью диаграмм, как показано ниже. Коммиты показаны буквой “o”, а связь между ними — линиями оканчивающимися – / и \. Время идет слева направо. Если нам нужно говорить о конкретном коммите символ “o” может быть заменён другой буквой или номером :


ooo «-- Branch A
/

ooo «-- master

\
ooo «-- Branch B

3.4. Понятие истории: Что такое ветка?

Когда нам нужно быть точными, мы будем использовать слово «ветка» (branch) которое означает линию разработки, и «вершина ветки» (или просто «вершина» (head)) означает ссылку на последний коммит на ветке .
В приведенном выше примере, вершина ветки имеет имя «А» и является указателем на один конкретный коммит, но когда мы ссылаемся на линию из трех коммитов до этой точки, мы называем эту цепочку коммитов «веткой А».


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

4. Действия с ветками

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

git branch
список всех веток

git branch «branch»

создать новую ветку с именем «branch», ссылающуюся на некотрую точку в истории
текущей ветки

git branch «branch» «start-point»

создать новую ветку с именем «branch», ссылающуюся на точку «start-point», которая
может быть указана так, как вы хотите – через имя ветки или имя тэга.

git branch -d «branch»

удалить ветвь «branch», если удаляемая вами ветвь имеет точки вне доступности от 
текущей ветки, то эта команда завершится неудачно с предупреждением.

git branch -D «branch»

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

git checkout «branch»

сделать ветку «branch» текущей, при этом обновляется рабочий каталог, отражая
состояние ветки «branch»

git checkout -b «new» «start-point»

создать новую ветку «new» ссылающуюся на «start-point», и сделать её текущей.

Специальный символ “HEAD” всегда означает вершину текущей ветки. Фактически, git использует файл с именем “HEAD” в .git каталоге, чтобы запомнить, текущую ветку :

$ cat .git/HEAD
ref: refs/heads/master

5. Изучение старой версия без создания новой ветки

Команда git-checkout, как правило, ожидает что вы укажете вершину ветки, но она также принимает произвольный коммит, например, вы можете проверить коммит, на который указывает тег:


$ git checkout v2.6.17

Примечание: переход к “v2.6.17”, который не входит в локальную ветвь. Если вы хотите создать новую ветку через checkout, вы можете сделать (сейчас или позже), используя команды checkout. Пример:

git checkout -b «new_branch_name»
HEAD is now at 427abfa... Linux v2.6.17

HEAD ссылается через имя SHA1 на коммит, а не на ветку, и git branch показывает, что вы вне ветки:

$ cat .git/HEAD
427abfa28afedffadfca9dd8b067eb6d36bac53f
$ git branch
(no branch)
master

В данном случае мы можем сказать, что вершина «отделена».


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

6. Изучение веток удалённого репозитория

Ветвь «master», которая была создана во время клонирования является копией HEAD клонированного репозитория.


Этот репозиторий, возможно, также имеет другие ветки, и в вашем локальном репозитории есть ветки, с помощью которых можно проследить каждую из этих удаленных веток, используя оппцию «-r» git-branch(1):

$ git branch -r
origin/HEAD
origin/html
origin/maint
origin/man
origin/master
origin/next
origin/pu
origin/todo

Вы не можете проверить их удалённо, но вы можете проверить их ветви в вашем репозитории, используя теги:

$ git checkout -b my-todo-copy origin/todo

Заметим, что название “origin” это просто название, которое git использует по умолчанию для обозначения репозитория, откуда был клонирован текущий репозиторий.

7. Имена веток, ярлыков, а также другие ссылки

Ветки, удалённое отслеживание веток и тэги – все это ссылки на коммиты. Все ссылки имеют полное имя с слеш-разделителем (косой чертой) и путем, которое начинается с “refs”; фактически раньше мы пользовались короткими именами (сокращениями):

* ветка «тест» это сокращение «refs/heads/test».
* тег “v2.6.18”' это сокращение «refs/tags/v2.6.18”.
* «origin/master» это сокращение «refs/remotes/origin/master»..

Полное имя может пригодиться, если, например, существует и тег, и ветвь с одним и тем-же именем. (Вновь созданные ссылки на самом деле хранятся в каталоге .git/refs по пути заданным их именем. Однако для эффективности они также могут быть упакованы вместе в один общий файл, см. git-pack-refs(1) ).


Другой, часто полезный ярлык это “HEAD”, на него можно сослаться только используя название репозитория. Так, например, “origin”, как правило, ярлык на HEAD ветки в репозитории “origin”.


Для полного списка путей которые git проверяют по ссылкам, и о порядке их использования для решения выбора, когда имеются несколько ссылок с одним сокращением, см. в выводе команды git-rev-parse(1) раздел SPECIFYING REVISIONS (Указание ревизий) .

8. Обновление репозитория через git fetch

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


Команда “git fetch”, без дополнительных аргументов, будет обновлять все отслеживаемые ветки до последней версии найденной в этом репозитории.
Это касается не только ваших веток, это коснётся и даже ветки “master”, которая была создана при вашем клонировании.

9. Извлечение веток из других репозиториев

Вы также можете отслеживать ветки из других репозиториев, отличных от вашего источника клонирования используя git-remote(1) :

$ git remote add linux-nfs git://linux-nfs.org/pub/nfs-2.6.git
$ git fetch linux-nfs
* refs/remotes/linux-nfs/master: storing branch 'master' ...
commit: bf81b46

Новая ветка удалённого отслеживания будут сохранена с коротким именем, которое вы задали в команде «git remote add», в данном случае c именем «linux-nfs»:

$ git branch -r
linux-nfs/master
origin/master

Если вы запустите «git fetch «remote»" позже, то отслеживаемая ветка с именем «remote» будет обновлена.


Если проанализировать файл .git/config, то можно увидить, как git добавляет новые блоки:

$ cat .git/config
...
[remote “linux-nfs”]
url = git://linux-nfs.org/pub/nfs-2.6.git
fetch = +refs/heads/*:refs/remotes/linux-nfs/*
...

Как git отслеживает удалённые ветки;
Вы можете модифицировать или удалять параметры конфигурации, редактируя файл .git/config в текстовым редакторе. (См. раздел “CONFIGURATION FILE” в выводе команды git-config(1) для изучения деталей).


Далее Содержание


 
Файлов нет. [Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]