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

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


Перевод A tutorial introduction to git (for version 1.5.1 or newer)


Оглавление документа


Это руководство объясняет, каким образом импортировать новый проект в 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 принять снапшот (снимок) содержимого всех файлов в текущем каталоге (обратите внимание на точку после add) с помощью комагды :

$ 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
#

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


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


$ 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.

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

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

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


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

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

в этой точке обе векки расходятся, с разными изменениями, внесенными в каждую из них.
Чтобы объединить изменения, сделанные в ветке 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
# первых несколько символов из имени, как правило хватает для идентификации коммита
$ git show HEAD
# показать последние изменения текущей ветки
$ git show experimental
# показать последние изменения ветки experemental

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

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

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

$ 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”, чтобы увидеть любой такой файл:

$ 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 может помочь вам выполнить бинарный поиск, ?что совершал?. Его смышлёности достаточно для выполнения приближенного к оптимального поиска даже в
случае сложной нелинейной истории с большим количеством объединений.
* 20 повседневных команд git
* git для пользователей CVS.
* Руководство пользователя GIT


Страницы, ссылающиеся на данную: AltLinux/Sisyphus/devel/git


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