Руководство пользователя GIT (для версии 1.5.3 и выше)

Перевод http://www.kernel.org/pub/software/scm/git/docs/user-manual.html

Оглавление

Предисловие 1

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

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

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

Понятие истории 4

Действия с ветками 6

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

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

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

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

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

Глава 2. Изучения истории Git 10

Предисловие

Git это быстро переносимая система управления версиями.

Данное руководство предназначена для чтения тем, кто имеет базовые знания UNIX и имеет навыки работы с командной строкой навыки, но не имеет знания по git.

В Главе 1, Репозитории и Ветки и в Главе 2, Изучение истории git объясняется, как получить и изучить проект используя GIT — читая эти главы, Вы узнаете, как собрать и проверить конкретную версию программного проекта, найти регрессии, и т..п..

Людям занимающимся актуальной разработкой будет также полезна Глава 3, Разработка с Git n глава 4, Совместная разработка.

Дальнейшие главы охватывают более специализированные темы.

Comprehensive reference documentation is available through the man pages.

Всестороннюю справочную документацию можно получить с помощью man страниц.

Для любой из команд, например команды, "git clone", просто наберите

$ man git-clone $ Человеком ГИТ-клон

См. также Приложение А, Краткий справочник Git для краткого обзора git команд.

Наконец, смотрите Приложение B, Заметки и планы дел этого руководства с целью, помочь сделать это руководство более полным.

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

Содержание Главы 1

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

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

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

Понятие истории 4

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

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

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

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

Действия с ветками 6

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

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

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

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

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

Как получить 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", в котором содержится вся история проекта .

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

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

...

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

Create a new branch head pointing to one of these versions and check it out using git-checkout(1) :

Создать новую вершину ветки указывающую на одну из этих версий и проверить её можно с с помощью 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

Note that if the current branch head was your only reference to a particular point in history, then resetting that branch may leave you with no way to find the history it used to point to; so use this command carefully.

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

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

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

Каждое изменение в истории проекта представлено в виде фиксации (коммита).

The git-show(1) command shows the most recent commit on the current branch:

Команда 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) {

As you can see, a commit shows who made the latest change, what they did, and why.

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

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

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

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

Это ямя объекта вычисляется как хэш его содержимого коммита, и вам гарантируется, что содержимое коммита не может изменится без изменения его имяни.

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

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

Каждый коммит (за исключением самого первого коммита в проекте) имеет родительские коммит, которые показывает, что произошло до этого коммита.

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

Тем не менее, коммиты не образуют простой список; git позволяет разделять линии разработки, а затем объединять их снова, и точки, где два направления разработки объединяются в одно называются "слиянием" (merge).

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

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

Далее, мы говорим, что коммит Х "доступен" от коммита Y, если коммит Х предок коммита

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

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

Мы будем иногда представлять git историю с помощью диаграмм, как показано ниже. Commits are shown as "o", and the links between them with lines drawn with - / and .

Коммиты показаны как буува "o", а связь между ними с линиями оканчивающимися - / и . Время идет слева направо:

o--o--o <-- Branch A
/
o--o--o <-- master

o--o--o <-- Branch B

Если нам нужно говорить о конкретном коммите символ "o" может быть заменён другой буквой или числом.

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

Когда нам нужно быть точными, мы будем использовать слово "ветка (branch)" которое означает линию разработки, и "вершина ветки" (или просто "вершинаа (head)") rjnjhjt означает ссылку на последний коммит на ветке .

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

However, when no confusion will result, we often just use the term "branch" both for branches and for branch heads.

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

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

Creating, deleting, and modifying branches is quick and easy; here's a summary of the commands:

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

git branch

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

git branch <branch>

создать новую ветку с именем <branch>, ссылающуюся на некоторцю точку в истории

текущей ветки

git branch <branch> <start-point>

создать новую ветку с именем <branch>, ссылающуюся на точку <start-point>, которая

может быть указана так, как вы хотите - через имя ветки или имя тэга.

git branch -d <branch>

удалить ветвь <branch>, если удаляемая вами ветвь имеет точки вне доступности от

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

git branch -D <branch>

even if the branch points to a commit not reachable from the current branch, you may know that that commit is still reachable from some other branch or tag.

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

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

команду, чтобы удалить ветвь.

git checkout <branch>

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

состояние ветки <branch>

git checkout -b <new> <start-point>

создать новую ветку <new> ссылающуюся на <start-point>, и проверьте его.

The special symbol "HEAD" can always be used to refer to the current branch. Специальный символ "HEAD" всегда может быть использован для обозначения текущей ветки. Фактически, git использует файл с именем "HEAD" в .git каталоге, чтобы запомнить, текущую ветку :

$ cat .git/HEAD

ref: refs/heads/master

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

Команда 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 мастер

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

This is an easy way to check out a particular version without having to make up a name for the new branch.

Это простой способ проверить конкретную версию не имя новой ветки.

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

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

Ветвь «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 использует по умолчанию для обозначения репозитория, откуда вы его клонировали.

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

Ветки, удалённое отслеживание веток и тэгb - все это ссылки на коммиты.

Все ссылки имеют имя с слеш-разделителем (косой чертой) в пути, имя начинаюся с "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" (специфичные версии) " .

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

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

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

Это касается не только ваших веток, это коснётся и даже ветки "master", который была создана при вашем клонировании.

Fetching branches from other repositories

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

Вы также можете отслеживать ветки от других репозиториев, отличных от вашего источника клонирования используя 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

New remote-tracking branches will be stored under the shorthand name that you gave "git remote add", in this case linux-nfs:

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

$ git branch -r

linux-nfs/master

origin/master

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

If you examine the file .git/config, you will see that git has added a new stanza:

Если проанализировать файл .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) для изучения деталей).

Учебник введение в git (для версии 1.5.1 или более поздняя версия)

Перевод http://www.kernel.org/pub/software/scm/git/docs/tutorial.html

Это руководство объясняет, каким образом импортировать новый проект в git, как внести в него изменения, а общие изменения с другими разработчиками.

Если вы в первую очередь заинтересованы в использовании git для извлечения проекта, например, для тестирования последней версии, вы можете начать с первых двух глав Git Руководства пользователя.

Во-первых, Вы можете получить документацию для команды, с помощью man, например :

 $ man git-diff 

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

Простейший способ сделать это:

 $ git config --global user.name "Your Name Comes Here"
 $ git config --global user.email you@yourdomain.example.com 

Импорт новых проектов

Пусть, у вас есть архив project.tar.gz с Вашей первоначальной работой.

Вы можете поместить его в git следующим образом :

 $ tar xzf project.tar.gz  
( разархивировать тарбол )
 $ cd project  
( перейти в project )
 $ git init 
( инициировать git )
git ответит :

 Initialized empty Git repository in .git 
( # Инициализировано пустоt Git хранилище в папке .Git / )

Теперь Вы инициализировали рабочий каталог, и вы можете заметить, что создан новый каталог с именем ".git".

Теперь, дайте команду git принять снапшот (снимок) содержимого всех файлов в текущем каталоге (обратите внимание на .) с помощью git-add(1) :

 $ git add .
( # Добавить в git )

Этот снапшот в теперь будет хранится в временной области, которая называется в git "индексом".

Вы можете превратить временное состояние индекса в постоянное состояние с помощью git-commit(1) :

 $ git commit
( # Git заключить, закрыть = git коммит )

Эта команда попросит ввести сообщение о совершённых изменениях.
Так Вы сохранили первую версию вашего проекта в git.

Внесение изменений

Модифицируйте некоторые файлы, а затем добавьте их обновленое содержаное в индекс:

 $ git add file1 file2 file3 
( #Git добавить file1 file2 file3 )

Теперь вы готовы совершить коммит (превращение временных изменений индекса в постоянные).

Вы можете увидеть, то, что будет совершено при коммите с помощью команды git-diff(1) c опцией —cached:

 $ git diff --cached 
 ( $ Git сравнение c кэшем )

(без —cached, git-diff(1) покажет вам, все изменения, кроме тех, которые есть только в индексе) Вы также можете получить краткий обзор состояния git репозитория (зранилища) git с помощью команды git-status(1) :

 $ git status  
 # On branch master 
 # Changes to be committed: 
 #   (use "git reset HEAD <file>..." to unstage) 
 # 
 #       modified:   file1 
 #       modified:   file2 
 #       modified:   file3 
 
 
($ статус git )
 # Ветка мастер
 # Изменения, которые будут совершенны:
 # (используйте "git reset HEAD <file> ..." для отмены)
 #
 # Изменён: file1
 # Изменен: file2
 # Изменен: file3
 # 

If you need to make any further adjustments, do so now, and then add any newly modified content to the index.

Если вам нужно делать какие-либо дополнительные коррективы, сделайте это сейчас, и добавте их в индекс.

И наконец, завершите свои изменения коммитом:

 $ git commit

После этого вы попадёте в редактор vi для ввода сообщения с описанием ваших изменений, а затем будет записан и закрыт новый варианта проекта (в случае ели вы не введёте сообщение, команда commit не будет выполнена).

Можно так-же вместо предварительного запуска git add , дать команду с опцией -a:
$ git commit -a

которая автоматически заметит изменения в файлах (но не новые файлы), добавит их в индекс, и закроет проект в один шаг.

Заметка по оформлению коммита:
Хотя это и не требуется, но удобно, когда сообщение состоит из короткой не более 50 символов строкой с кратким изложением изменения, затем пустой строкой, и далее из более подробного описания изменения. На подобии email - в первой строке - суть изменений, а остальное в теле сообщения.

Git отслеживает содержание в индексе

Многие системы контроля версий отрабатывают команду "add", которая сообщает системе, что надо начинать отслеживать изменения в новых файлах.

Команда "add" в делает это более просто и мощно: git add добавляет в индекс как новые файлы, так и модифиии изменённых файлов. В обоих случаях создаётся новый снапшот с учетом новых файлов и измений в старых файлах, включаемый в индекс, который всегда готов для включения в следующую фиксацию (коммит).

Просмотр истории проекта

В любой момент Вы можете просмотреть историю изменения проекта комадой :

 $ git log
( $ Git журнал )

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

 $ git log -p 

Можно  получить с информацией о каждом шаге изменения

 $ git log --stat --summary 
($ Git журнал - статистика - Итоги )

Управление ветками

Один репозиторий Git может состоять из нескольких веток разработок.

Для создания новой ветки с названием "experimental", можно дать команду :

 $ git branch experimental 
($ Git ветка )

Для получения списка всех существующих веток Вы можете запустить :

 $ git branch

   experimental 
 * master 
 
"Experimental"  - это созданная Вами ветка, а "мастер" ветвь автоматически создаваемая по-умолчанию.
 Звездочка отмечае текущую ветвь (ветвь с какой вы сейчас работаете).
Команда :

$ git checkout experimental 
переключит вас на ветвь experimental.

Now edit a file, commit the change, and switch back to the master branch:

Теперь отредактируйте файл, закфиксируйте изменения коммитом и вернитесь в ветку master:

 (edit file)  (измените файлы)
$ git commit -a  
$ git checkout master 

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

Вы можете внести изменения в ветке мастер:

 (edit file)  (измените файлы)
$ git commit -a 

at this point the two branches have diverged, with different changes  made in each. 

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

 $ git merge experimental 
( $ Git объединить )

Если изменения не конфликтуют между собой, всё выполнится сразу.

Если есть конфликты, слева от проблемных файлов будут выставлены маркеры конфликта.

Команда

 $ git diff 

покажет это.

После того вам надо отредактировать файлы для устранения конфликтов.

Команда 

 $ git commit -a 

завершит  слияние ветвей

Наконец команда,

 $ gitk 

покажет историю в графическом представлении.

Теперь вы можете удалить ветвь experimental

 $ git branch -d experimental 

Эта команда гарантирует, что изменения в ветке  experimentalуже есть в текущей ветке.

Если вы разрабатывали ветку crazy-idea, а потом разочаровались в неё, вы всегда сможете удалить ветвь с

 $ git branch -D crazy-idea 

Ветки это просто и ясно, так что это хороший путь для разработки чего-то нового.

Совместное использование git

Предположим, что Алиса начала новый проект в git репозитории в /home/alice/project, и Боб которые имеет домашний каталог на этой машине, хочет внести свой вклад в этот проект.

Боб начинает с:

 $ git clone /home/alice/project myrepo 

Эта команда создает новый каталог "myrepo" у Боба, который содержат точную копию (клон) репозитория Алисы. Клон имеет
одинаковую основу  с оригинальным проектом, так-как  обладает своей собственной копией истории оригинального проекта.

Теперь Боб делает некоторые изменения и фиксирует их:

 (edit files) (редактировать файлы)
$ git commit -a   
(повторять по мере необходимости)

Когда всё готово, Боб предлагает Алисе взять его изменения из его репозитория в /home/bob/myrepo.
Алиса делает так:

 $ cd /home/alice/project  
 $ git pull /home/bob/myrepo master 

Это объёдиняет ветку "master" репозитория Боба с текущеё веткой Алисы.
Если Алиса делала в это время свои собственные изменения, то ей, возможно, придется вручную устранять возникающие конфликты.(Заметим, что аргумент "master" в вышеуказанной команде, на самом деле не нужен, так-как он применяется по-умолчанию).

Команда "pull", таким образом, выполняет две операции: она извлекает (fetch) изменяется из ветки удалённого репозитория , а затем объединяет (merge) их с текущей веткой.

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

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

 $ git remote add bob /home/bob/myrepo 

При этом Алиса может выполнять первую операцию отдельно, используя git fetch команду без слияния её с текущей веткой:

 $ git fetch bob 

В отличие от длинной формы, когда Алиса извлекает  (fetches) из удаленного репозитория Боба, короткая форма извлечения (fetches)
сохраняет загруженые изменения не в текущей ветке, а  в отдаленной ветке , в данном случае bob/master. 

После этого делаем:

 $ git log -p master..bob/master 

Смотрим список всех изменений, что сделал Боб, после ответвления его репозитория от ветки master репозитории Алисы.

После изучения этих изменений, Алиса может объединить изменения в ее ветку master:

 $ git merge bob/master 

Это объединение также может быть сделано через путём git pull  из её собственногой удалённой ветки:

 $ git pull . 


Заметим, что git pull всегда объединяет c текущей веткой, независимо от того, что еще дается в командной строке.

Позже, Боб может обновить его репозиторий от Алисы до последнего изменения с помощью

 $ git pull

Имейте в виду, что ему не нужно давать путь к репозиторию Алисы; когда Боб клонироваk Алисин репозиторий, то он сохранил его местоположение в конфигурациии репозитории, и теперь использует его для pull:

 $ git config --get remote.origin.url  /home/alice/project

(Полная конфигурация созданная git-clone видна командой "git config -l", а man gitt-config(1) объясняет значение каждого параметра).

Git также сохраняет нетронутым копию Алисиной ветки master под названием "origin/maste":

 $ git branch -r    origin/master 

Если позже Боб решит работать с различными хостами, он может выполнять clone и pull с помощью ssh протокола:

 $ git clone alice.org:/home/alice/project myrepo 

Альтернативно, git имеет свой протокол, или использует или rsync или http; подробнее см. git-pull(1).

Git также может быть использовать CVS-подобный режим, с центральным репозитотием, который использует команду git push для внесения изменений, см git-push(1) и git для пользователей CVS.

Изучение истории

История Git представляется как серия взаимосвязанных фиксаций (коммитов).

Мы уже видели, что команда git log может выдать список коммитов

Заметим, что первая строка каждого git log входит также в имя для коммита:

 $ git log  
 commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7 
 Author: Junio C Hamano <junkio@cox.net>  
 Date:   Tue May 16 17:18:22 2006 -0700        
 merge-base: Clarify the comments on post processing.

Мы можем также задать это имя в git show, что-бы посмотреть детали об этой этой фиксации.

 $ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7 $ Git шоу c82a22c39cbc32576f64f5c6b3f24b99ea8149c7 

Но есть и другие способы для обозначения коммитов (фиксаций).

Вы можете использовать любыe начальнe часть имени, которое является достаточно большими, чтобы однозначно идентифицировать коммит:

 $ git show c82a22c39c   
 # the first few characters of the name are                          
 # usually enough 
 $ git show HEAD        
 # the tip of the current branch 
 $ git show experimental
 # the tip of the "experimental" branch

 $ Git show c82a22c39c
 # первые несколько символов из имени, как правило хватает
 $ git show HEAD
 # показать последние изменения текущей ветки
 $ git how experimental 
 # показать последние изменения ветки experemental

Every commit usually has one "parent" commit which points to the previous state of the project:

Каждый коммит, как правило, имеет одного "родителя" который является предыдущим состояния проекта:

 $ git show HEAD^ 
 # to see the parent of HEAD 
 $ git show HEAD^^
 # to see the grandparent of HEAD 
 $ git show HEAD~4
 # to see the great-great grandparent of HEAD

 $ Git show HEAD ^
 # Смотрим родителя HEAD 
 $ git show HEAD ^ ^
 # смотрим предыдущего родителя
 $ git show HEAD ~ 4
 # смотрим  пред-предыдущего родителя

Note that merge commits may have more than one parent:

Заметим, что после слияния коммит, может иметь больше чем одного родителя:

 $ git show HEAD^1
 # show the first parent of HEAD (same as HEAD^) 
 $ git show HEAD^2
 # show the second parent of HEAD
 
 $ Git show HEAD ^ 1 
 # показать первого родителя HEAD (он же HEAD^) 
 $ git show HEAD ^ 2 
 # показать второuj родителя HEAD 

Вы также можете дать коммиту своё имя; после запуска

 $ git-tag v2.5 1b2e1d63ff 

Вы можете обратиться к 1b2e1d63ff под названием "v2.5".
Если вы намерены поделиться этим именем с другими людьми (например, для
идентификации версии), вам следует создать "tag" (метку) объекта, и, возможно,
подписать его, подробнее см. git-tag(1) .

Любой комаде git, для которой требуется имя коммита можно указать любое из этих имен коммита.

Например:

 $ git diff v2.5 HEAD   
 # compare the current HEAD to v2.5 
 $ git branch stable v2.5
 # start a new branch named "stable" based   
 # at v2.5 
 $ git reset --hard HEAD^
 # reset your current branch and working                          
 # directory to its state at HEAD^
 Будьте осторожны с этой последней командой: помимо потери каких-либо изменений в рабочем каталоге, при этом также будут
удалены все более поздние коммиты. Если эта ветвь  содержащит коммиты они будут потеряны. Кроме того, не используйте "git reset" в
публично-опубликованной ветке, так-как другие разработчики взявшие отсюда изменения, будет вынуждены при объединении  
очищать историю. Если вам нужно отменить изменения, что у вас уже сделаны, применяйте git-revert(1) 

Команда git grep может искать строки в любой версии вашего проекта, так:

 $ git grep "hello" v2.5 Git

ищет все вхождения "hello" в v2.5.

Если вы опускаете имя коммита , git grep будет искать во всех файлах зафиксированных в текущем каталоге.

 $ git grep "hello" Git 

это быстрый способ найти только среди файлов, которые отслеживаются git.

Многие команды git также имеют установки коммитов, которая могут быть указаны множеством способов.

Вот несколько примеров из git log:

 $ git log v2.5..v2.6           
 # commits between v2.5 and v2.6 
 $ git log v2.5.. 
 # commits since v2.5 
 $ git log --since="2 weeks ago"
 # commits from the last 2 weeks 
 $ git log v2.5..
 # commits since v2.5 which modify                                 
 # Makefile Makefile

Вы также можете дать в git log "диапазон" где первый коммита не обязательно предок второго, например, если заметки от "stable-release" и "master" вышли от общих коммитов какое-то время назад , тогда

 $ git log stable..experimental

выдаст лист коммитов, сделанных в экспериментальной ветви,  в то время как

 $ git log experimental..stable 

покажет список коммитов стабильной ветки, но не экспериментальная ветви.

Команда "Git log" имеет недостаток: он должен предъявить коомиты в виде списка.

Когда история имеет линии развития, которые расходятся, а затем объединены обратно вместе, порядок, при котором в котором "git log" представляет эти коммиты теряет смысл.

Большинство проектов с несколькими участниками (например, ядром или сам git) часто сливаются, и gitk улучшает визуализацию их истории.

Например,

 $ gitk --since="2 weeks ago" drivers/ 

позволяет просматривать все коммиты за последние 2 недели в которых менялись файлы в каталоге drivers. 
(Заметка: вы можете настроить в gitk шрифты, удерживая ctrl и нажимая "-" или "+".)

И наконец, большинство команд, которые принимают имена файлов опционально позволяют предшествовать любым именам файлов для коммита, чтобы определить конкретную версию файла:

 $ git diff v2.5:Makefile HEAD:Makefile.in 

Вы также можете использовать "git show", чтобы edbltnm любой такой файл:

 $ git show v2.5:Makefile $ Git шоу v2.5: Makefile 

Следующие шаги

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

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

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

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

Если Вы не хотите продолжатьизучать его сразу, есть несколько других источников, которые могут быть интересны Вам на данный момент :

• git-format-patch(1) , git-am(1) : Эти преобразователи из серии git коммиты в патчи в формате электронной почты, и обычно, полезно для проектов, таких как linux ядро, которое в значительной степени полагаются на патчи по электронной почте.

• git-bisect(1) : Когда есть регресс в вашем проекте, одним из способов выслеживать ошибкой является поиск через историю, чтобы найти точный адресс неправильного изменения.Git bisect может помочь вам выполнить бинарный поиск, что совершал.
  Его смышлёности достаточно для выполнения приближенных к оптимальным поиск даже в случае сложных нелинейных история с большим количеством филиалов объединений.

• Ежедневник GIT with 20 Commands Or So

• git для пользователей CVS.

• 
  

Init

Стартовое сообщение