Архив метки: vcs

Git, краткий справочник команд

Содержание
1. Введение
2. Настройка Git-репозитория (git config)
2.1. Справка
2.2. Чтение списка настроек
2.3. Добавление настроек
2.4. Чтение отдельной настройки
2.5. Поиск отдельной настройки
3. Создание Git-репозитория (git init)
4. Состояние репозитория (git status)
5. Подготовка файлов к фиксации (git add)
6. Фиксация изменений (git commit)
7. Возврат к любой фиксации (git checkout)
8. Работа с ветвями (git branch)
9. Обзор изменений (git diff)
10. Обзор лога фиксаций (git log)
11. Создание наблюдений (git remote)
12. Загрузка удалённого репозитория (git fetch)
13. Слияние двух состояний (git merge)
14. Обновление репозитория (git pull)
15. Клонировать репозиторий (git clone)
16. Втолкнуть изменения в удалённый репозиторий (git push)
17. Откат изменений (git reset)
18. Создание отметок готовности (git tag)
19. Заключение

Введение

Эта статья является продолжением предыдущей статьи Git, краткая теория.
Сегодня мы рассмотрим работу с Git на практических примерах. (Используется Git версии 1.7.8.msysgit.0)
В Git есть хорошая практика, которая рекомендует перед началом работы с репозиторием представиться ему, указав своё имя и электронный ящик для обратной связи. Поэтому работу с Git мы начнём с описания команд работы с конфигурацией Git
Сделаю важное замечание, я не буду углубляться во всё многообразие способов вызова той или иной команды Git, наоборот — я приведу конкретные команды для получения нужного результата.

Настройка Git-репозитория (git config)

Как говорилось в прошлой статье, настройки Git придерживаются стандартной архитектуры настроек Linux. Настройки могут быть: локальные (—local), пользовательские (—global), системные (—system).
Настройки распределены по секциям, подсекциям и имени параметра:

section.subsection.name = value

В файле конфигурации эти параметры располагаются следующим образом:

[section "subsection"]
    name = value

Все составляющие имени параметра разделяются точкой.
Подсекция может состоять из любого кол-ва подсекций:

section.subsection1.subsection2.subsectionN.name = value

Но в файле настроек всё выглядит точно так, как и раньше:

[section "subsection1.subsection2.subsectionN"]
    name = value

Справка

git help config

получить справку по работе с командой git config

Чтение списка настроек

git config -l

весь список настроек, применяемых для текущего репозитория (сумма всех уровней настроек)

git config —local -l

список только локальных настроек репозитория из файла .git/config

git config —global -l

список пользовательских настроек из файла ~/.gitconfig (Заметка: в Windows путь к домашней папке можно явно указать через переменную окружения $HOME)

git config —system -l

список системных настроек из файла /etc/gitconfig

cat .git/config
находясь в папке репозитория можно просто вывести файл настроек (команда cat не относится к git)

Добавление настроек

git config [—system | —glogal | —local] —add имяСекции.имяПеременной значениеПеременной

общий синтаксис добавления нового параметра в файл конфигурации. По умолчанию новый параметр добавляется в —local, если не указанного другого назначения.

git config user.name YourName
git config user.email YourEmail@email.x

добавить настройку в локальный конфигурационный файл, атрибут —add может быть опущен, хотя я его пишу для наглядности. Смотреть следующий пример для подробностей.

git config —add user.name YourName
git config —add user.email YourEmail@email.x

добавить информацию о вашем имени и электронном ящике в секцию user локального репозитория.
Но чтобы не выполнять эту операцию для каждого репозитория, вы можете добавить эти настройки в пользовательский файл конфигурации:

git config —global —add user.name YourName
git config —global —add user.email YourEmail@email.x

теперь информация об имени и эл. ящике записана в ~/.gitconfig, и будет применяться автоматически для всех репозиториев текущего пользователя системы.

git config —global —add user.name «YourName YourSurname»

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

Чтение отдельной настройки

git config —get user.name

вернёт значение настройки user.name, которая применяется к текущему репозиторию

Поиск отдельной настройки

git config —get-regexp regexpName [regexpValue]

возвращает список настроек, удовлетворяющих установленным регулярным выражениям. regexpName — регулярное выражение для имени параметра. regexpValue — регулярное выражение для значения параметра.

git config —get-regexp user

вернёт все настройки, в имени которых встречается слово «user».

git config —get-regexp ^user

вернёт все настройки, имя которых начинается на «user». Говоря иначе — вернёт все настройки из всех секций [user].

git config —global —get-regexp ^user

получить список настроек секции «user» только из файла пользовательских настроек ~/.gitconfig

git config —global —get-regexp remote

получить информацию о секциях «наблюдения» и ассоциациях текущих веток с удалёнными ветками

Создание Git-репозитория (git init)

Команда git init создаёт новый репозиторий

git init

создать «простой» репозиторий в текущей папке. Это основной репозиторий, с которым нам предстоит работать.

git init —bare

создать «голый» репозиторий в текущей папке (используется как централизованное хранилище при централизованном стиле разработки).

git init repo

создать новую папку repo в текущей папке и создать в ней репозиторий

git init —bare repo

аналогично предыдущему примеру, но создаётся «голый» репозиторий

Состояние репозитория (git status)

Команда git status позволяет узнать текущее состояние репозитория.

git status

показать текущее состояние репозитория

Подготовка файлов к фиксации (git add)

Команда git add добавляет файл или группу файлов в index (staging area). (В дальнейшем добавленные файлы могут будь зафиксированы в репозитории командой git commit

git add .

добавить все файлы и папки текущей директории в index (staging area)

git add path/to/file1

добавить только один файл (или папку) в staging area

Фиксация изменений (git commit)

Команда git commit переносит изменения из index (staging area) в local repo.
После оп
ерации фиксации вам необходимо заново заполнять область index (staging area)

git commit -m «Комментарий к фиксации»

фиксирует изменения, добавленные в staging area, в репозитории. Заметьте, чтобы зафиксировать изменения, их надо сначала добавить в staging area командой «git add .«.

git commit -a -m «Комментарий к фиксации»

фиксирует все изменения, сделанные в working directory. Особенность этой команды в том, что перед ней не нужно выполнять команду «git add .» (это не распространяется на новые файлы, которые ещё никогда ранее не добавлялись).

Возврат к любой фиксации (git checkout)

Команда git checkout позволяет загрузить любое состояние репозитория в working tree.
При возврате к фиксации, work tree переходит в состояние на тот момент фиксации: исчезают файлы, которых не было в тот момент, появляются файлы, которые были на тот момент. (Заметка: checkout можно выполнить, только тогда, когда у вас нет никаких изменений в текущем состоянии working tree. В ином случае вам следует их зафиксировать или отказаться от них).

git checkout nameBranchOrCommit

где nameBranchOrCommit — либо первые четыре (или более) символов имени фиксации, либо имя ветки.
Имя фиксации — это сорока символьная строка, например: b4d470fc242c41d1e270a4041edf673586f8325a

git checkout b4d4

переключиться на фиксацию с именем, начинающимся на «b4d4». Заметка: при таком переключении у вас меняется текущая ветка на ветку «(no branch)». Заметка: вы можете указать имя фиксации, которая располагается в любой ветви и вы будете перенесены на эту точку фиксации.

git checkout master

переключиться на ветвь master (переключение происходит на верхушку ветви)

git checkout master~1

переключиться на одну фиксацию назад относительно верхушки ветви master

git checkout head~1

переключиться на одну фиксацию назад относительно текущего вашего положения.
Заметка: при каждой операции checkout ссылка head указывает на текущее положение.
Заметка2: не рекомендуется создавать ветвь с одноимённым названием head, т.к. head — это ссылка на текущее состояние.

git checkout b4d47~2

переключиться на две фиксации назад относительно фиксации с именем, начинающимся на «b4d47».

git checkout -b branchName nameBranchOrCommit

переключается на фиксацию nameBranchOrCommit и тут же создаёт от неё новую ветвь branchName и переключается на эту ветвь.

Работа с ветвями (git branch)

Команда git checkout обеспечивает работу с ветвями. Просмотр, создание и удаление ветвей разработки

git branch

просмотреть список существующих ветвей и узнать какая ветвь выбрана текущей

git branch -r

просмотреть список удалённых ветвей (ветвей из репозиториев, за которыми мы «наблюдаем»);

git branch branchName

создать ветвь с именем name. Создание ветви не приводит к переключению в эту ветвь, для этого используйте команду git checkout branchName. Созданная ветвь ответвляется от текущего состояния репозитория.

git branch -d branchName

удаляет ветвь branchName. Если ветвь ещё не была с лита с основной ветвью, то git предупредит об этом и удаления не будет

git branch -D branchName

удаляет ветвь branchName, даже если вы ещё не сливали её изменения с основной ветвью

Обзор изменений (git diff)

Команда git diff позволяет увидеть изменения между разными состояниями фиксаций, или между текущими изменениями и последней фиксацией.

git diff

показать изменения между work tree и index (staging area)

git diff —cached

показать изменения между index (staging area) и local repo

git diff master~2..master

показать суммарные изменения, произошедшие при перемещении от фиксации master~2 к фиксации master.
Заметка: если вы только добавляли текст, то будут отображаться «плюсики» в начале добавленных строк.

git diff master..master~2

показать суммарные изменения, которые произошли при перемещении от фиксации master к фиксации master~2.
Заметка: в отличии от предыдущего примера, здесь будет показано, что строки были удалены — знаки «минуса» в начале строк.

</div >

git diff otherBranch..master

показать суммарные изменения между последней фиксацией в ветви otherBranch и последней фиксации в ветви master.
Заметка: возможно такое сравнение не будет иметь смысл, если ветви не имеют общего предка, но… всё на ваше усмотрение.

Обзор лога фиксаций (git log)

Команда git log позволяет увидеть историю фиксаций от начала до текущего состояния HEAD.

git log

показать историю фиксаций от начала до текущего состояния HEAD.

git log nameBranchOrCommit

показать историю фиксаций от начала до указанной ветви или имени фиксации

git log anyBranch~1

показать историю фиксаций от начала до предпоследний фиксации на ветви anyBranch

git log master~2..master

показать историю фиксаций от пре-предпоследней фиксации до последней фиксации по ветви master
Заметка: обратите внимание, что запись «git log master..master~2» не покажет ничего.

git log br1..master

покажет историю фиксаций от места ответвления ветки br1 (от ветки master) до текущего состояния по ветке master.
Заметка: ветка br1 должна быть ответвлена от ветки master

git log br1…master

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

git log HEAD

то же, что и «git log«, покажет историю фиксаций от начала до текущего состояния

git log FETCH_HEAD

покажет историю фиксаций от начала до состояний FETCH_HEAD
Заметка: состояние FETCH_HEAD становится доступным после выполнения операции git fetch или git pull.

git log HEAD..FETCH_HEAD

покажет историю фиксаций по текущей ветви начиная от места, где совпадают состояния HEAD и FETCH_HEAD, и до конца истории.

git log HEAD…FETCH_HEAD

покажет историю общую фиксаций от места, где совпадают состояния HEAD и FETCH_HEAD, и до конца истории.

Создание наблюдений (git remote)

Команда git remote применяться для создания «наблюдений» за другими репозиториями. Позволяет удобно сливаться с другими репозиториями.

git remote

выводит список существующих «наблюдений»

git remote add name path

добавляет новое наблюдение с именем name до репозитория, расположенного по пути path.

git remote rm name

удаляет наблюдение с именем name вместе с данными, которые были загружены в это наблюдение. (На репозиторий за которым «наблюдали» эта операция никак не влияет!)

Загрузка удалённого репозитория (git fetch)

Команда git fetch позволяет загрузить удалённый репозиторий в раздел «наблюдения» локального репозитория. Загрузить репозиторий — ещё не значит «слиться» с ним. Для слияния используется команда git merge.

git fetch

подгружает данные по текущей ветке из соответствующей ветки удалённого репозитория, или подгружает данные из соседней ветки локального репозитория

git fetch repo branch

подгружает содержимое ветки branch репозитория repo в объект состояния FETCH_HEAD.

Слияние двух состояний (git merge)

Команда git merge выполняет слияние двух состояний HEAD и FETCH_HEAD в новое HEAD состояние. Если происходит конфликт изменений, то эти файлы выходят из index (staging area), до тех пор, пока вы не исправите конфликт и не поместите их обратно в index командой «git add .«.
Команда слияния всегда занимает отдельную фиксацию, при слиянии не допускается изменение каких-либо файлов

git merge branch

слить ветку branch с текущей веткой.

Обновление репозитория (git pull)

Команда git pull выполняет подгрузку удалённого репозитория и производит слияние с ним. Данная операция аналогична последовательному выполнению двух операций: git fetch и git merge.

git pull

обновить текущую ветку репозитория до состояния другой локальной или удалённой ветки репозитория

Клонировать репозиторий (git clone)

Команда git clone создаёт копию репозитория и устанавливает настройки для наблюдения за оригинальным репозиторием. Эти настройки применяются в командах fetch, push, pull.

git clone repo newRepo

создаёт полный клон репозитория repo в репозиторий newRepo (папка нового репозитория создаётся автоматически).

Втолкнуть изменения в удалённый репозиторий (git push)

Команда git push позволяет втолкнуть изменения текущего репозитория в удалённый. По умолчанию, вталкивать данные можно только в «голые» репозитории.

git push

вталкивает данные всего локального репозитория в соответствующие ветки удалённого репозитория

git push origin master

вталкивает данные текущей ветви в ветвь master удалённого репозитория origin. Если ветвь master не существует в удалённом репозитории, она будет создана. Если для удалённой ветви невозможно выполнить FAST-FORWARD слияние, то данные не будут «втолкнуты» (об этом будет сообщено).
Заметка: данный способ вызова команды является первым при первой фиксации в пустой удалённый репозиторий.

Откат изменений (git reset)

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

git reset

отменит операцию слияния, но оставит изменения в конфликтующих файлах и/или в index области. При этом состоянии Git будет ожидать от вас фиксации или полной отмены изменений.

git reset —hard

отменит операцию слияния, очистит index область и вернёт все файлы work tree до состояния последней фиксации по текущей ветви.

Создание отметок готовности (git tag)

Команда git tag позволяет отметить текущее состояние, как некоторое конечное состояние для новой версии вашего проекта. Используется для создания списка стабильных версий проекта. Заметка: имя метки tag может использоваться в командах checkout и других командах, на ровне с именами фиксаций, именами ссылок (HEAD, FETCH_HEAD) и именами веток (master и т.п.).

git tag

показать список существующих tag-ов

git tag -m «описание» tagname

создать метку tag для текущего состояния (на текущей ветке) с именем tagname.

git tag -d tagname

удалить метку tag с именем tagname

Заключение

В этой части мы кратко рассмотрели список наиболее часто используемых команд при работе с Git. В следующей части мы рассмотрим практические примеры работы с Git.
Читать далее: Git в примерах
Смотрите также:

Автор: galiego710

Git, в примерах

Введение

В этой части мы рассмотрим работу с репозиторием git на примерах

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

Читать →

Git, краткая теория

Содержание
1. Введение
2. Git, описание
2.1. Общее
2.2. О репозитории
2.3. Настройки репозитория
2.4. Отношения между репозиториями
2.5. Одиночная работа
2.6. Распределённая работа
2.6.1. Распределённая структура разработки
2.6.2. Централизованная структура разработки
2.7. Ветви в репозитории
2.8. Общие понятия в репозитории
3. Заключение

Введение

Git (произн. «гит») — это распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005 года.

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

Помимо Git есть много других систем управления версиями (VCS, Version Control System), одной из которых является свободная (и бесплатная) система Subversion (кратко SVN).

Subversion (также известная как «SVN») — свободная централизованная система управления версиями, официально выпущенная в 2004 году компанией CollabNet Inc.

Обо всём этом можно подробно прочитать в других источниках. Здесь же я опишу своё краткое представление о Git, которое у меня сложилось при работе с ним. Описание не претендует на полное и всеобъемлющее.

Описание будет в виде коротких тезисов и абзацев

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

Git, описание

Общее

Git — это распределённая система управления версиями.

С git можно работать и локально и удалённо.

Репозиторий (хранилище) — это место, где хранится наши данные: история изменений нашего проекта

Репозиторий Git — это всегда локальный репозиторий

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

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

О репозитории

В Git, в отличии от Subversion, есть два типа репозитория: «простой» и «голый»

Простой репозиторий — это основной репозиторий, с которым вам предстоит работать. В нём вы можете выполнять большинство команд git. Такой репозиторий содержит подпапку .git/

Голый репозиторий — этот репозиторий часто, применяемый для ведения разработки в централизованном стиле. Данные репозитория не помещаются в подпапку .git/, а размещаются непосредственно в корне папки репозитория

Настройки репозитория

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

Каждый репозиторий Git имеет свои собственные настройки, располагаемые в файле .git/config

Вообще настройки репозиториев Git соответствуют общей архитектуре настроек в Linux. А именно, это означает, что настройки разделены на три уровня:

Уровень 1. Локальные настройки репозитория, применяются только к одному конкретному репозиторию, располагаются в каждом отдельном репозитории в файле .git/config
Уровень 2. Пользовательские настройки репозитория, применяются ко всем репозиториям пользователя, и располагаются в домашней директории пользователя в файле ~/.gitconfig (Для Windows путь к домашней директории вы можете явно указать в переменной окружения HOME)
Уровень 3. Системные настройки, применяются ко всем репозиториям всех пользователей системы, располагаются обычно в файле /etc/gitconfig (для Windows это может быть файл «c:Program Files (x86)Gitetcgitconfig»)

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

Отношения между репозиториями

Репозиторий Git — это всегда локальный репозиторий, располагающийся в своей папке

Для репозитория есть понятие «наблюдать за другим репозиторием» (это понятие я придумал сам), на практике выражается использованием команд git remote в консоли и секций [remote «имя_наблюдения»] в файле конфигураций репозитория

Один репозиторий может:

не наблюдать ни за кем
или наблюдать за любым кол-вом репозиториев

Репозиторий A может загрузить полное (или частичное) содержимое репозитория B, даже если A «не наблюдает» за B, и даже если A не имеет общей истории с B.

«Загрузить» (git fetch) внешний репозиторий и «слиться» (git merge) с репозиторием — разные вещи! Мы всегда можем загрузить содержимое внешнего репозитория, посмотреть его историю изменений, но не прибегать к слиянию с ним.

Допустим, в репозитории A вы создали наблюдение с именем seeB за репозиторием B (git remote add seeB path/to/B). Но важно помнить, что «наблюдение» не обновляется автоматически. Это значит, что спустя время, git не сообщит вам об изменениях в репозитории B. Узнавать об этом вам необходимо самим — просто загрузив свежую версию репозитория B командой git fetch seeB. «Наблюдение» — это не какая-то система слежения, а просто копия репозитория B в одной из падпапок .git/ репозитория A.

Одиночная работа

Создав репозиторий, в него можно фиксировать изменения (git commit), просматривать логи изменений (git log), загружать указанную или последнюю версию фиксации (git checkout)

Одиночная работа с репозиторием сводится к тому, что вы делаете некоторые изменения в файлах и фиксируете их (подробнее об этом написано в статье «Название статьи»)

Распределённая работа

Командная работа над проектом (репозиторием) начинается тогда, когда кто-то клонирует его.

Клонировать репозиторий — значит скопировать весь репозиторий полностью: вместе со всей его историей изменений.

Один репозиторий может быть клонирован любым кол-вом людей.

Чтобы слить два репозитория в будущем, их не обязательно клонировать изначально, но клонировать удобнее, т.к. автоматически добавляется информация о «наблюдении за оригинальным репозиторием» в настройках клона.

Когда разработчик 2 внёс изменения в склонированный ранее репозиторий, он сообщает об этом разработчику 1. И тот «забирает» его изменения от себя используя команду git pull (или две последовательные команды git fetch и git merge). После этого разработчик 1 сообщает разработчику 2, что он принял изменения, после этого 2-й разработчик обновляет свой склонированный репозиторий командой git pull, и продолжает разработку.

Разработчик 2 не смог бы «втолкнуть» (git push) свои изменения в репозиторий разработчика 1, т.к. по умолчанию это запрещено (для больших подробностей смотрите опцию receive.denyCurrentBranch настроек репозитория)

Втолкнуть изменения из репозитория B в репозиторий A, без его ведома A можно в том случае, если репозиторий A является «голым» (т.е. создан командой git init —bare).

Распределённая структура разработки

Есть группа разработчиков. Каждый имеет свой собственный «простой» (git init) репозиторий. У каждого настроены «наблюдения» за репозиториями соседей. Каждый разработчик сам загружает к себе чужие изменений. Никто из разработчиков не может ни кому «втолкнуть» свои изменения.

Централизованная структура разработки

Существует центральный «голый» (git init —bare) репозиторий. Все остальные разработчики отклонировались от центрального репозитория. Каждый разработчик сначала вносит изменения в свой локальный репозиторий-клон, а потом «вталкивает» (git push) свои изменения в центральный сервер.

Ветви в репозитории

Используйте команду git branch, чтобы просмотреть список существующих веток в репозитории и узнать какая ветка сейчас выбрана активной

Используйте
команду git branch -r, чтобы просмотреть список веток в существующих «наблюдениях» репозитория

Ветка в репозитории — это альтернативный путь развития проекта

Репозиторий может содержать любое кол-во веток

При создании веток не происходит физического копирования файлов хранилища. Поэтому даже создав много веток, это не отразится сильно на размере репозитория

Две ветви одного репозитория могут быть слиты в одну ветку (git merge)

Создать новую ветку можно двумя способами:

создать явно командой git branch имя_ветки
или неявно: откотиться назад до любой фиксации, внести изменения и зафиксировать эти новые изменения.

Git защитит вас, если вы попытаетесь удалить ветку (git branch -d имя_ветви), изменения которой вы ещё не сливали в главной ветвь. Но если вы всё же хотите удалить ветвь без слияния с основной ветвью, используйте команду git branch -D имя_ветви

Общие понятия в репозитории

Репозиторий имеет несколько важных понятий, о которых важно знать, чтобы поняь принцип работы с репозиторием.

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

Index (staging area) — незримая область, в которой хранятся отметки о файлах, изменения в которых вы собираетесь зафиксировать

Local repo — ваш локальный репозиторий.

Remote repo — это удалённый репозиторий, который может находиться как в другой папке на вашем компьютере, так и на другой машине в сети.

Таким образом процесс работы с репозиторием сводится к следующей простой схеме:

вы вносите изменения в working directory
добавляете желаемые изменения в область staging area
фиксируете изменения в репозиторий local repo

Также есть ещё несколько понятий, значение которых я ещё не уловил до конца:

HEAD — ссылка на текущее состояние репозитория
FETCH_HEAD — ссылка на состояние репозитория, загруженное в эту ссылку командой git fetch или git pull

Заключение

Более подробно о работе git я расскажу в следующей статье. Данная статья служит лишь общим каркасом для понимания общих идей и принципов работы git. Всё, о чём говорилось здесь, мы рассмотрим в следующей статье на примерах

Читать далее: Git, краткий справочник команд

Смотрите также:

Автор: galiego710

Git, установка

Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005 года.
В этой статье я кратко опишу как устанавливать git.

Если вы работаете в Windows, то взять git для установки можно по этой ссылке: Git-1.7.8-previewXXXXXXXX.exe.
Желающие также могут установить графический клиент TortoiseGit для работы с git, но все наши примеры будут для командной строки.

Установка Git в Windows

Запускаем Git-1.7.8-previewXXXXXXXX.exe, оставляем всё по умолчанию, дожидаемся завершения работы установщика. После инсталляции, вы можете запустить консоль для работы с git:

"ПускПрограммыGitGit bash"

Быстрый запуск консоли для git

Конечно, запускать консоль мышью через меню каждый раз — дело утомительное. Поэтому предлагаю немного оптимизировать этот процесс.
1. На основном диске создайте папку

C:bin

2. Создайте файл C:bingitbash.bat со следующим содержимым:

@%WINDIR%system32cmd.exe /c ""C:Program Files (x86)Gitbinsh.exe" --login -i"

Обратите внимание, что путь «»C:Program Files (x86)Gitbinsh.exe» у вас может быть другим. Всю эту строчку я взял из поля «Объект» свойства ярлыка «ПускПрограммыGitGit bash».

3. Добавьте путь C:bin в переменную PATH среды Windows.

Свойства «Мой компьютер» вкладка «Дополнительно» кнопка «Переменные среды…» блок «Системные переменные».
Найдите в списке переменную «Path», выберите её, нажмите «Изменить». Допишите в конец значения переменной следующую строку:

;C:bin

Нажмите Ок Ок Ок

Готово! Теперь, если у вас уже была открыта командная строка, её нужно закрыть и запустить снова. Теперь из любой папки мы можем написать gitbash для запуска командной строки для работы с git.

Читать далее: Git, краткая теория

Список сайтов:
Установка и настройка git и gitosis в Ubuntu
DVCS Git и TortoiseGit в картинках. Пособие для начинающих чайников.

Смотрите также:

Автор: galiego710

Системы контроля версий. Git.

Решил всё-таки написать некое введение в тему, чтобы бы было куда давать ссылки 😉 Примечание: информация расчитана на не очень опытных разработчиков. Профессионалам, думаю, все освещенные здесь вопросы покажутся тривиальными. Товарищам, знакомым с контролем версий, но не знакомым с Git, предлагаю первые разделы пропустить.

Что такое управление версиями и зачем оно?

Итак, предположим, вы разрабатываете программу. Для простоты сначала предположим, что вы разрабатываете ее в одиночку и для собственного удовольствия. Как это выглядит?

Создаем директорию MyApplication, в ней — собственно файлы программы (скажем, *.c). Далее начинается итерационный процесс: написали некоторое количество кода → скомпилировали → запустили → обнаружили ошибки или недоработки → отредактировали исходники → … Всё просто, в целом. Но через некоторое время начинаются нетривиальные вещи. Например:

Последнее изменение сделало программу хуже, чем она была до того. Хочется вернуть всё «как было». Хорошо, если не успели закрыть редактор — делаем Undo. А если закрыли?
Хотим приделать к программе новую функциональность, но сразу ясно, что, во-первых, сразу после написания она будет глючить (т.к. еще не отлажена), а во-вторых, в сложной программе добавление новой функциональности может добавить ошибок в ранее работавшую часть программы. Хочется, в случае чего, откатиться к заведомо работающему варианту и начать всё сначала.
Если программа предназначена не только для вас лично, то вам придется делать»релизы», т.е. выпускать заведомо работающие версии программы. Для подготовки релиза вам придется фиксить некоторое количество багов. Это довольно скучный процесс, хочется разбавлять его добавлением новых возможностей в программу (это, как правило, интереснее). Но нельзя: добавление новых фич обязательно добавит багов, и вы никогда не доедете до релиза.

Первое, что приходит в голову для решения всех этих проблем — резервные копии. Скажем, каждую работающую версию программы упаковывать в MyApplication_v0.001.tar.gz, в случае чего — откатываться. Для подготовки к релизу — сделать копию директории MyApplication, в которой только фиксить баги, а в основной — добавлять функционал. При этом подходе через некоторое время разработки у вас появится куча *.tar.gz и не меньше копий рабочей директории. Очень быстро вы начнете путаться, где что.

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

Вы добавили в программу (в свою копию) возможность A, а ваш товарищ (в свою) — возможность B. Хотелось бы, чтобы у обоих была версия с обоими возможностями.
Вы добавили в программу некоторую функцию, ваш товарищ добавил ее же, но реализовал по-другому. Какую версию выпускать и поддерживать дальше?
Ваш товарищ в какой-то момент разработки понял, что программу можно улучшить и упростить, если изменить ее архитектуру, что-то обобщить, что-то вынести в отдельный модуль и т.п., и начал переделку (это называется умным словом рефакторинг). Вы же в это время в старой версии программы находите баги и фиксите их. Т.к. в версии вашего товарища в основном тот же код, эти баги наверняка есть и там — хотелось бы их сразу пофиксить.

Даже в случае двух разработчиков, при «ручном» согласовании изменений после определенного объема программы эти неочевидности превращаются в окончательную неразбериху. При разработке сколько-нибудь большой программы в конторе «ручное» согласование изменений видится почти невозможным.

Все эти проблемы призваны решить специальные программы — системы контроля версий (version control systems, vcs).

Общие свойства VCS

Если вы работаете с vcs, то у вас есть место, где хранится вся история изменений в программе — это место называется репозиторий (repository). Для внесения изменений в программу вам нужно получить копию текущей разрабатываемой версии — она называется вашей рабочей копией (working copy). Процесс получения рабочей копии традиционно называется словом «чекаут» (checkout). В случае коллективной разработки, вам придется поддерживать актуальность вашей рабочей копии (проверять, что там остальные наработали) — это обычно называется «апдейт» (update). Чтобы ваши изменения попали в репозиторий, вам нужно сделать коммит (commit) (еще это называется словом checkin). Ча
сто словом commit называют собственно сам набор изменений, зафиксированный этой операцией (более точный термин — changeset). Каждое зафиксированное изменение называют ревизией. Вы можете в любой момент откатить свою рабочую копию к любой предыдущей ревизии — это называется revert.

Для того, чтобы отслеживать такие вещи, как релизы, или варианты рефакторинга программы, или тестировать версии с новыми функциями — в репозитории создаются ветви разработки (branches). Для согласования хода разработки в разных ветках (она может вестись, и обычно ведется, параллельно) время от времени делают слияние веток (merge) — когда к одной ветке применяются те же изменения, что были проделаны в другой. Если какое-то место какого-то файла было по-разному изменено в разных ветках, при слиянии возникает конфликт (merge conflict) — его приходится решать вручную, выбирая один из вариантов или как-то логично их объединяя.

Так как ревизий в репозитории обычно довольно много, возникает необходимость некоторые из них как-то помечать (например, выпущенные релизы, или просто состояния программы, в которых она заведомо работала). Такие пометки называют тегами (tags). Таким образом, теги — это поименованные ревизии в репозитории.

Автоматизация всех перечисленных операций — дело VCS.

Централизованные vs распределенные VCS

Всё множество VCS можно разделить на два класса — централизованные и распределенные.

В случае с централизованной VCS репозиторий хранится на одном сервере, и все разработчики работают с ним. Очевидное преимущество: простое управление выпуском релизов и вообще ходом развития программы, раз весь код в одном месте. Очевидный недостаток: если с сервером что-то случится, работа всех разработчиков пропадет (даже в случае регулярных бэкапов — пропадет работа всех разработчиков, скажем, за последнюю неделю). Известные примеры централизованных vcs — CVS, Subversion, Perforce.

В случае с распределенной VCS, каждый разработчик имеет полную копию репозитория и работает с ним, время от времени синхронизируясь с репозиториями остальных. Таким образом, для организации целенаправленной разработки потребуются какие-то не технические, а организационно-административные средства. Зато получаем множество преимуществ:

Раз у каждого есть полная копия репозитория, работа всех разработчиков пропасть не может вообще.
Часто выполняемые операции — прежде всего, commit — происходят почти мгновенно, т.к. не требуют соединения по сети.
Каждый разработчик может создавать в своем репозитории ветки для каких-то экспериментов, всем остальным даже не нужно знать об этом.
Т.к. в распределенных VCS предполагается регулярная синхронизация репозиториев, в них гораздо более эффективно реализована операция слияния веток (здесь это одна из базовых операций, в отличие от централизованных VCS, где это делается нечасто).
Каждый разработчик может взять («утянуть») у другого один или несколько коммитов, применив их к своему коду.

Git

Git — это одна из распределенных VCS (distributed version control system, dvcs). Другими примерами dvcs являются Mercurial, Bazaar, Monotone.

Git выделяется на их фоне главным образом из-за того, что он применяется для разработки ядра Linux (http://www.kernel.org). Собственно, именно для этого Git и разрабатывался. Ядро Linux — весьма немаленький проект, как по объему исходного кода, так и по числу участников, поэтому при его разработке большое внимание было уделено производительности и легкости слияния веток.

Далее я привожу часто используемые команды git. Я опускаю кучу тонкостей и многие возможности Git. Всё это можно посмотреть в документации (git help имя-команды, например git help commit). Здесь — скорее отправная точка, свод основных возможностей Git.

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

$ cd project
$ git init

— создаем пустой репозиторий.

$ git clone git://remote.server/repo.git

— клонируем существующий репозиторий. Кроме собственного протокола, git поддерживает http://, ssh:// и пр.

При создании репозитория в его корневой директории появляется скрытая директория .git — она содержит собственно репозиторий, т.е. историю версий итп. Все остальное содерж