Система git: Git и командная разработка (для чайников) / Хабр

git config --global user.name "Your Name" 
git config --global user.email [email protected]

[user] 
name = John Doe 
email = [email protected]

mkdir first_git_repo 
cd first_git_repo 
git init

git log
git log --graph

git checkout sha1_hash 
git checkout первые_8_цифр_sha1

git checkout b1 
git merge b2

Работа с распределенной системой контроля версий Git на примере GitHub / ХабрРабота с распределенной системой контроля версий Git на примере GitHub
Год начала данной публикации: 2019
Год окончания данной публикации: не указан

Теоретическая часть
Практическая часть
Настройка программы Git
Инициализация локального репозитория
Работа с удаленным репозиторием
Чтобы некоторые ваши файлы не попадали в репозиторий
Модели ветвления в Git
Выводы
.gitignore. Отправка только тех файлов в репозиторий, которые необходимы

Предупреждение по использованию:

Данная публикация является учебной для освоения основ системы контроля версий git, на примере использования GitHub. Это не руководство к действию. Вы должны понимать, то что вы делаете применяя команды и идеи изложенные в публикации. Не спешите применять сказанное к вашим рабочим проектам. Создайте черновой проект, локальный репозиторий. Потренируйтесь на нем. Создайте свой учебный проект на GitHub. Когда вы хорошо будете понимать, что и как работает, только тогда вы сможете применить ваши знания в рабочих проектах. Публикация не является переводом какой либо работы. Это авторская работа с целью прояснить некоторые вопросы. Более подробно смотрите раздел: «Цель публикации».

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

Что не должно попасть в удаленный репозиторий:
Лишние файлы конфигурации, исполняемые файлы, временные файлы, ключи к репозиторию, платежные ключи(когда вы работаете над платежными сервисами и системами наподобии Amazon). В ветки master и release не должны попасть изменения от начинающих, неопытных программистов и некачественный код, не прошедший тестирование.

Обязательно прочитайте в документации: что не должно попадать в GitHub и как настроить .gitignore.

Система контроля версий довольно сложная штука. Но пусть вас это не пугает. Попробуем разобраться. Дать определения, и внести ясность. Если вы работаете один над своим проектом, то вам даже не обязательно регистрироваться на сервере. Вы можете просто установить себе Git и работать с системой контроля версий локально. Вам для локальной работы над проектом не обязательно даже будет подключение к интернету. Репозиторий который вы создаете локально — это фактически такой же репозиторий как на сервере, только без возможности работать над проектом распределенной команды разработчиков. Система контроля версий — по существу это реализация права программиста на ошибку в своем коде. Как вы помните «человеку свойственно ошибаться». Так вот, ошибаться программисту следует гораздо меньше. И, чтобы вернуться к своему коду и исправить ошибку, добавить функциональность и существует такая замечательная система, как система контроля версий. Кроме того использование системы контроля версий — это более эффективный менеджмент.

Ответьте на вопрос: В чем заключается работа в команде и вы поймете насколько управление проектом становится более эффективным с системой контроля версий. Еще одно преимущество: Система контроля версий облегчает процесс ревью(пересмотра, доработки) кода. Следующее преимущество: Автоматическое разрешение конфликтов. То есть объединение, например разных версий методов, сделанных разными разработчиками в одну ветку. Здесь, в данном материале я не рассматриваю плагины для git в IDE. Здесь рассматриваются только общие вопросы работы с git и работы с удаленным репозиторием на GitHub.

Контрольные вопросы:
В чем заключается экономия времени при использовании системы контроля версий?
В чем преимущества использования системы контроля версий?
Что такое Git?
Как начать использовать git?
Как начать использовать GitHub?
Основные(наиболее часто используемые) команды Git.
Какие сервисы существуют для Git?
Как работать с локальным репозиторием?
Как работать с распределенным репозиторием?

Git-хостинг на разных условиях предлагают многие компаний.
Довольно известные из них: Github, Sourceforge, Google Code, GitLab, Codebase и тд.

Сервисы git в порядке популярности(тут, чтобы не возникло холивара, допишу: По моему мнению):

1. Ваш локальный сервис, использование git только локально
2. GitHub
3. BitBucket
4. GitLab

Про использование своего git сервера вы можете прочитать на хабре >>>

В данной публикации я рассматриваю в основном работу с сервисом GitHub.

Цель публикации: Коротко рассказать что такое Git.

Описать некоторые, основные команды консоли Git. Хотя в интернет существует довольно много описаний работы с git, многое из документации может показаться запутанным и некоторые определения раскрыты не полностью. Что может ввести начинающих в заблуждение. Некоторые определения следует написать в более развернутом виде, для ясности понимания.
Также с практическими примерами намного легче освоить систему. Цель статьи сделать небольшой обзор о системе Git. Показать как использовать некоторые команды, для более быстрого освоения начинающими. Показать как настроить систему для конкретного использования. Следующая цель, предотвратить бездумное использование тех или иных команд Git.

Предметная область и основные термины

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

Git — одна из распределенных систем контроля версий.
GitHub — один из сервисов для использования системы контроля версий Git.

repository — некоторое хранилище файлов, ссылок на изменения в файлах
commit — отслеживание изменений, сохраняет разницу в изменениях
HEAD — (специальный указатель) символическая ссылка на последние изменения. Примечание: Не обязательно ссылается на commit. Может указывать на ветвь. Состояние — «Detached HEAD»
HEAD используется репозиторием для определения того, что выбрано с помощью checkout.
Обратите внимание на это различие: «head» (в нижнем регистре) относится к любому из названных заголовков в хранилище; «HEAD» (верхний регистр) относится исключительно к текущему активному заголовку(ссылке). Это различие часто используется в документации Git. HEAD может указывать на именованную вершину какой-либо ветки или на commit.
Объекты Git. Четыре типа объектов: Blob, Tree, Commit и References.
Ветвь определяется не в самом Git, а наследуется от операционной и файловой систем.
Более подробно об объектах Git вы можете прочитать в документации.

git сервисы — сервисы предоставляющие услуги для пользователей git.

HEAD — указатель на текущую ветку. Текущая ветка. Более подробно: Ваше рабочее дерево обычно получается из состояния дерева, на которое ссылается HEAD. HEAD — это ссылка на один из заголовков в вашем хранилище, за исключением случаев использования отдельного HEAD, в этом случае он напрямую ссылается на произвольный коммит

.

working directory — рабочий каталог на вашем компьютере
staging area — область подготовленных файлов или рабочая область
branch — ветка, состоит из набора коммитов, обычно ссылается на последний коммит
merge — слияние, слияние веток в одну
pull — втянуть, взять проект с сервера, получить изменения из удаленного репозитория
push — вытолкнуть, отправить изменения на сервер

Символы:
# — в данном случае символ комментария
<> — угловые скобки, там где вам нужно вписать нужное исключая эти скобки
$ — приглашение ввода в терминале

Небольшое вступление

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

Git — одна из систем контроля версий.

Предназначена, в основном, для работы распределенной команды разработчиков.
То есть разработчики могут находиться в разных концах света и работать над одним проектом.
Нет Git используют не только разработчики, но и дизайнеры, писатели, редакторы, проектировщики, переводчики. GitHub часто используют hr специалисты и hr менеджеры для поиска успешных кандидатов на те или иные вакасии в различных областях. Для математического анализа успешности проектов.
Система Git очень экономична и не требует рассылки большого количества файлов. Отслеживаются и пересылаются изменения в файлах и ссылки на эти изменения. То есть основная рассылка это рассылка разницы в ваших редактированиях.

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

История создания

Цитата из Вики:

Git (произнoсится «гит»[8]) — распределённая система управления версиями. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005 года. На сегодняшний день его поддерживает Джунио Хамано.

Теоретическая часть(коротко)

Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux
Git свободная система и распространяется она под лицензией GNU GPL 2.

Git is an Open Source project covered by the GNU General Public License version 2 (some parts of it are under different licenses, compatible with the GPLv2).

Основная задача системы управление версий — это упрощение работы с потоками изменяющейся информации. Главной парадигмой системы управления версий является локализация данных каждого разработчика проекта. Каждый разработчик имеет на своей машине локальный репозиторий. В случае необходимости изменения отправляются из локального репозитория в удаленное хранилище в определенную ветку. И любой разработчик из распределенной команды может скачать новые изменения в проекте, чтобы продолжить совместную работу над проектом. Тут я сделаю некоторую ремарку. Важно соблюдать стандарты по оформлению кода и работе с системой в вашей организации. Стандарты облегчают взаимодействие между разработчиками, экономят время, облегчают понимание того что вы делаете. Некоторая этика и культура по оформлению кода, по оформлению и структурированию рабочего процесса помогает разработчикам лучше и быстрее понимать друг друга.

Какие существуют системы управления версиями:
1. Централизованные
2. Децентрализованные(распределенные)

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

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

Взаимодействие с другими системами контроля версий
В стандартной поставке Git поддерживается взаимодействие с CVS (импорт и экспорт, эмуляция CVS-сервера) и Subversion (частичная поддержка импорта и экспорта). Стандартный инструмент импорта и экспорта внутри экосистемы — архивы серий версионированных файлов в форматах .tar.gz и .tar.bz2.

Fork – удаленная копия репозитория на сервере, отличная от оригинала. Это даже не git-концепция, а, скорее, политико-социальная идея. Clone – это не то же самое, что и fork. Клон удаленного репозитория располагается локально. Фактически при клонировании копируются все данные, включая историю коммитов и существующие ветки.
Branch, или создание ветки, – это способ внести изменения в проект и объединить их в итоге с остальным кодом. Ветка является частью репозитория.

Рабочее дерево (рабочая директория, рабочее пространство) – это дерево исходных файлов, которые вы можете видеть и редактировать.
Индекс (область подготовленных файлов, staging area) – это один большой бинарный файл .git/index, в котором указаны все файлы текущей ветки, их SHA1, временные метки и имена. Это не отдельная директория с копиями файлов.
Указатель HEAD – это ссылка на последний коммит в текущей извлеченной ветке.

Некоторое отступление от темы: Зачем я так много привел цитат?
Ответ самый простой. Чтобы в дальнейшем дать более точные и ясные определения.

Практическая часть

Для использования системы git вам нужно:

1. Установить программу git на вашей системе.
2. Настроить программу и проверить её работоспособность локально
3. Зарегистрировать ваш аккаунт на GitHub
4. Создать локальный репозиторий или копировать репозиторий существующего проекта
5. Написать файл README.MD.
6. В случае, если вы начинаете проект, создать удаленный репозиторий
7. Фиксировать изменения локально
8. Отправлять изменения на GitHub
9. Зарегистрировать аккаунты разработчиков вашего проекта
10. Выдать им ссылку на проект

1. Установка git

В Linux:

sudo apt-get update && sudo apt-get upgrade #обновление перед установкой

sudo apt-get install git #установка git

В Windows:
Git для Windjws >>>

1. После установки вы можете кликнуть правой кнопкой мышки на папке в проводнике Windows и выбрать открыть «Git Bash Here». Git Bash Here — означает отрыть терминал git здесь.

В терминале введите команду

git --version #вывод версии

проверить версию вашего git.

В Linux,(Ctrl+Alt+T — терминал, если у вас не назначены другие горячие клавиши) откройте терминал и введите

git --version

В случае успешной установки на консоль выведется версия вашего git.

2.Настройка программы Git

Примечание:
Тут следует упомянуть, что настройку Git вы осуществляете на нескольких уровнях.
То есть некоторые настройки вы делаете для определенного пользователя операционной системы(не системы git, а операционной системы). Другие настройки вы делаете для всех пользователей операционной системы. Далее вы можете делать настройки для определенной папки(локально). Вы делает настройки для репозитория находящегося на сервере. Эти настройки вы можете не делать, если работаете только со своим локальным репозиторием.
В данной публикации я рассматриваю команды консоли в основном Windows git-bash.
Более подробно об отличиях вы можете посмотреть в документации. Упомяну только что есть некоторые отличия. Например в параметрах пути к файлам и папкам. В Windows используется / — слеш, а в Linux обратный слеш \. Хотя в Windows вы можете самостоятельно настроить на использование обратного слеша.

Настройка пользователя и емейл:

git config --global user.name "My Name"

git config --global user.email [email protected]

Чтобы ввести настройки только одного репозитория, перейдите в его папку и сделайте то же без —global:

Настройка внешнего редактора.

git config --global core.editor emacs  #подключить внешний редактор emacs

#команда для Linux.
Вы можете выбрать другой текстовый редактор. Например не emacs, a vi или nano или другой на ваше усмотрение.

В Windows, такой командой вы можете задать текстовый редактор, например notepad++.

For x64 Windows change to: git config —global core.editor «‘C:/Program Files (x86)/Notepad++/notepad++.exe’ -multiInst -notabbar -nosession -noPlugin»

Для x64 Windows вы можете использовать команду(только пропишите свой путь):

git config --global core.editor "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin" 

Настройки git хранятся в файлах.

Git проверяет 4 места для файла конфигурации(здесь в Linux):
Файл вашего компьютера .gitconfig.
Ваш пользовательский, файл вашего пользователя .gitconfig файл находится в ~/.gitconfig.
Второй пользовательский файл конфигурации, расположенный в $ XDG_CONFIG_HOME/git/config или $HOME/.config/git/config.
Конфигурационный файл локального репозитория: .git/config

cat .git/config #просмотр конфигурации локального репозитория

Каждый файл добавляет или переопределяет параметры git, определенные в файле над ним.

Конфигурация системы.
Конфигурация пользователя.
Конфигурация, специфичная для репозитория.

Ссылка на документацию >>>

Вы можете просмотреть файлы конфигурации

#для системы и всех пользователей

git config --system --list

git config --system --edit

#для пользователя

git config --global --list

git config --global --edit

Проверка настроек вашей конфигурации git:

git config --list #вывести на экран конфигурацию.

Если список большой, вы можете пролистывать его с помощью стрелок клавиатуры или «pg up», «pg dn». Для выхода клавиша q.

#какая конфигурация, где установлена:

git config --list --show-origin

Для чего нужно рассмотреть консольные команды? Ведь существуют UI.
Часто в консоли вы можете сделать, что-то гораздо быстрее. С помощью набора консольных команд вы сами в будущем сможете автоматизировать процесс. Консольные команды более гибкий инструмент. Почему? Да потому что ваш UI может и «не знать» о существовании той или иной команды. UI может вообще отсутствовать как таковой, например на сервере ввиду своей небезопасности. На первом этапе консольные команды во многом помогут в общем понимании того как работает система. Все их запоминать нет необходимости. Вы в любой момент сможете найти справку по той или иной команде. Теоретические знания, без которых никуда, лучше усваиваются с применением на практике.

Команды Git(консольные)

git опции команда аргументы 

пример:

git branch -d <name> # удалить локальную ветку с именем name 

git branch -d bugFix00 #удалить локальную ветку с именем bugFix00.

Опции:
-C — использовать указанную папку репозитория вместо текущей папки;
-c параметр=значение — использовать указанное значение параметра конфигурации;
-p — прокручивать весь вывод с помощью less;

Инициализация локального репозитория.

1. Переходим в папку проекта.

cd ваша_папка #команда терминала, переход в папку с именем ваша_папка 

2.

git init #инициализация локального репозитория

3.

git add . #тут мы добавляем все. 

Папку. Точка после add отделенная пробелом.
Можно добавить отдельный файл
Например

git add имя.расширение

Таким образом мы говорим — отслеживать изменения нашего файла.
Для добавления всего в папке рекомендуют использовать команду

git add -A

4. Создание commit

git commit #сохранить изменения в локальном репозитории

-m «комментарий» #аргумент создания комментария коммиту. Ваши изменения будут уже с осмысленным комментарием.
Вы можете использовать полное имя ключа, вместо его сокращения. К примеру, вместо -m вы можете использовать —message=«комментарий»

git commit --message="$Ваш осмысленный комментарий"

Тут нужно сделать некоторое замечание. Чтобы использовать русские буквы в комментариях, нужно сделать предварительные настройки. Вам нужно настроить кодировку символов в системе, кодировку символов в текстовом редакторе или IDE, кодировку символов в терминале, кодировку символов в git. Другой момент: Windows «не любит» одиночные апострофы, поэтому коментарий заклечен в кавычки. На Linux есть возможность использовать апострофы при оформлении коментария к коммиту.

5.

git show #показать изменения внесенные вашим коммитом

6.

git status  #просмотр текущего состояний git

Показывает информацию — какая ветка текущая.
Какие файлы изменены и тд. Команда показывает, что находится в рабочей области(в staging area).

Ветки. Branches

Ветка(branch) — ссылка на определенный коммит.

Создание ветки.

git branch имяВетки #будет создана ветка с именем "имяВетки"

, используйте для имени латинские буквы. Тут есть одно замечание. Когда мы создали ветку с некоторым именем, текущей осталась ветка, которая была выделена до этого. Ну например master. И если после создания ветки мы скажем git commit, то будет продолжена ветка master. Не понимание этого часто приводит к ошибкам.

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

1. Создаем ветку:

git branch feature #создание ветки с именем "feature" локально

2. Переключаемся на созданную ветку:

git checkout feature#выбор ветки с именем "feature" локально

3. Делаем commit:

git commit

Теперь у нас есть вторая ветка с именем feature.

Объединение веток(merge).
Объединение веток создает коммит от двух родителей, от текущей ветки и ветки указанной в команде git.

1. Переключаемся на ветку master
2. Сморим какая ветка текущая
3. Объединяем ветки

git merge feature  #объединить текущую ветку с веткой feature

Мы можем сделать по другому. Переключиться на ветку feature и объединить её с веткой master

1.

git checkout feature #выбор ветки feature 

2.

git merge master #объединить текущую ветку

, в данном случае feature c веткой master.

Просмотр доступных веток:

git branch -v -a #просмотреть все доступные ветки, которые можно получить

git diff --cached #посмотреть какие изменения добавились в stage

stash — стек, временное хранилище
Не путайте со stage, это не одно и то же.

Команда

git stash

сохраняет все не закомиченные изменения во временное хранилище и сбрасывает состояние ветки до HEAD.

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

Стеш(stash) предназначит для того, что бы спрятать не нужные на данный момент изменения, потому он и называется stash, в переводе — прятать, припрятывать.

git stash apply #применить изменения к текущей версии
git stash list  #вывести список изменений
git stash show #вывести последние изменения
git stash drop #удалить последние изменения в списке 
git stash pop  # [apply] + [drop]
git stash clear #очистить список изменений

git stash drop# удалит последний git stash

git stash drop stash@{5}#удалит git stash под номером 5

рис 1.

На рисунке показана подготовка папки на локальном компьютере для git.
Добавление в staging area. Добавление изменений в локальный репозиторий(git commit).
Отправка в удаленный репозиторий(git push).
На данной схеме не показана сущность stash.

рис 2.

На диаграмме рис 2. показана работа команд add, commit all, commit, reset, git reset head, git update index.

Untacked files — непроиндексированные файлы.
Working tree — ваша рабочая папка
Index — индексация файлов
Commit — изменения файлов

Здесь нужно внести некоторую ясность. Диаграмма относится к вашему локальному репозиторию. Но это другой вид диаграммы. Это как будто мы рассматриваем работу git c различных точек, под «разным углом». Показан некоторый жизненный цикл индексации изменений локального репозитория.

Работа с командами:

cherry-pick
reset
revert
rebase
merge

Очень полезные команды. Рассмотрите их самостоятельно.

Работа с удаленным репозиторием

Далее я перейду к описанию работы с удаленным репозиторием.
Вы можете работать с удаленным репозиторием и вашим проектом через протокол [url]https://,[/url]
то есть в вашем браузере(chrome, mozilla, opera и других).

GitHub.com >>>
Интерфейс GitHub на английском языке.

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

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

git init #инициализация локального репозитория

git add -A

Подключить ветку на удаленном(в данном случае GitHub) компьютере:

git remote add origin https://github.com/имя_ник_пользователя/ИмяРепозитория.git

«имя_ник_пользователя» — в данном случае ник пользователя удаленного репозитория.
«ИмяРепозитория» — в данном случае это имя вашего уже созданного заранее репозитория на GitHub

Показать какие пути назначены:

git remote -v

Вывод:

origin  [url]https://github.com/имя_пользователя/имя_репозитория.git[/url] (fetch)
origin  [url]https://github.com/имя_пользователя/имя_репозитория.git[/url] (push)

 git remote show #показать какие ветки есть в удаленном репозитории

Обычно там одна ветка origin.
То есть это не сама ветка, а её сокращенное название ассоциированное с репозиторием.
Вы можете добавить, ассоциировать еще одну ветку на удаленном репозитории.

git remote add <сокращенное_имя_удаленного_репозитория> [email protected]:имя_пользователя/имя_удаленного_репозитория.git

git remote add <имя_удаленного_реп> протокол@github.com:пользователь/имя_удаленного_репозитория.git

имя_удаленного_реп — имеется в виду короткое имя которое будет ассоциировано с удаленным репозиторием.
имя_удаленного_репозитория — имеется в виду имя репозитория на сервере. То есть имя удаленного репозитория.

git remote set-url origin [url]https://имя_пользователя@github.com/имя_пользователя/test.git[/url] #установить новый путь 

git pull origin master #забрать все изменения с сервера из ветки origin  в локальную ветку master 

Только данная команда забирает одну ветку из удаленного репозитория.
Кроме того она сливает(объединяет, merge) все изменения из удаленного репозитория с вашими локальными. Эту команду следует применять, когда вы только начинаете работать с удаленным репозиторием и у вас своих наработок в локальном пока нет.

git remote -v #показать путь к удаленному репозиторию

git clone --recursive https://github.com/имя_пользователя/имя_репозитория.git #рекурсивное получение репозитория

 git clone --recursive https://github.com/имя_пользователя/имя_удаленного_репозитория.git Lимя_локальной_папки

Эта команда создает папку с именем Lимя_локальной_папки.
Берет все изменения из репозитория «github.com/имя_пользователя/имя_удаленного_репозитория.git» и сохраняет их в папке «Lимя_локальной_папки».
Здесь я написал префикс L перед именем папки, чтобы отличить локальную папку от удаленной на сервере.

gitk #утилита отображения графа изменений

Диаграмма ниже показывает отличие работы с локальным репозиторием и с репозиторием на GitHub
[url]https://greenido.files.wordpress.com/2013/07/git-local-remote.png?w=696&h=570[/url]

Из данной диаграммы вы можете видеть, как работать с локальным репозиторием и как работать с репозиторием на сервере. Показаны только несколько команд для краткости и ясности.
Ваш локальный репозиторий находящийся на одной вашей рабочей станции — это такой же репозиторий. Вы можете не регистрироваться на GitHub или других серверах, а работать локально. Вам даже не нужно для этого подключения к интернет. У вас будет локальный репозиторий и контроль версий. Такие же ветки, по которым вы можете переключаться, объединять их и тд. То есть полноценно работать локально, как с сервером.
При желании, вы сможете потом отправить их на сервер.

Чтобы некоторые ваши файлы не попадали в репозиторий.
Вы хотите чтобы некоторые файлы не индексировались и не попадали в репозиторий?
Вам нужно создать файл с именем .gitignore.

touch .gitignore #создает пустой файл .gitignore

В терминале cmd windows:

type nul > .gitignore #создает пустой файл .gitignore

Пустой созданный файл .gitignore вам ничего не дает. Чтобы некоторые файлы не отправлялись на сервер, вам нужно задать в этом файле правила.
Вы можете скачать готовый файл .gitignore с GitHub. Там есть специальный репозиторий, в котором сохраняются шаблоны .gitignore для разных языков и фреймворков.
Репозиторий gitignore >>>

По умолчанию файл .gitignore не добавляется в репозиторий.
О файле .gitignore вы можете прочесть в документации:
git-scm.com/docs/gitignore
Приводится пример файла и кратко описывается его синтаксис.

Вы можете создать глобальный файл для пользователя

git config --global core.excludesfile ~/.gitignore_global #создает ссылку на файл .gitignore_global

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

git config --get core.excludesfile #показывает где должен находиться файл .gitignore_global

Вам осталось создать этот файл. Откройте терминал(В Windows cmd).

cd c:\путь\где\должен_находиться_файл .gitignore_global

type nul > .gitignore_global #создать пустой файл .gitignore_global

Вы можете скопировать готовый файл отсюда >>>
Откройте ваш пустой файл .gitignore_global в текстовом редакторе и скопируйте текст из готового файла в ваш. Сохраните файл.

рис 3.

На данной диаграмме показана работа команд: git add, git commit, git push и git fetch.

Предупреждение:

git push -f #чревато потерей данных при работе с веткой нескольких человек…

git push --force #чревато потерей данных при работе с веткой нескольких человек…

git fetch #забирает изменения с сервера, но только в локальный репозиторий

Команда fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент.

git pull #берет данные с сервера в локальный репозитория и сливает их с рабочей веткой.

Проще говоря,

git pull 

состоит из двух команд:

git fetch

и

git merge

.

Опции(ключи) -n, —dry-run #многие команды git имеют данные ключи. Эти опции нужны для того чтобы посмотреть какие изменения сделает команда.

То есть, вы можете увидеть результат выполнения данной команды и затем применить её при уверенности без ключей -n, —dry-run

Модели ветвления в Git:

Для чего нужны модели ветвления?
Для лучшей организации потока работы(Workflow). Для стандартизации. То есть в вашей организации может быть принята, в зависимости от целей некоторая модель ветвления.

Central Workflow
Developer Branch Workflow
Feature Branch Workflow
Issue Branch Workflow
Forking Workflow
Patch Workflow

Central Workflow (центральный рабочий процесс) в этом контексте определяется как «вы отправляете изменения тому же репозиторий, из которого вы обычно получаете свои последние вышестоящие изменения», независимо от того, используете ли вы rebase или merge. (pull = fetch + merge или fetch + rebase, в зависимости от конфигурации и параметров)

Feature Branching являет логическим расширением Central Workflow (центрального рабочий процесса). Основная идея рабочего процесса Feature Branch: разработка всех функций должна осуществляться в выделенной ветви вместо основной ветви. Главная ветвь никогда не должна содержать неработающий код. Это является большим преимуществом в средах непрерывной интеграции.

Gitflow Workflow
Рабочий процесс Gitflow был впервые опубликован в блоге Винсента Дриссена от nvie за 2010 год. Рабочий процесс Gitflow определяет строгую модель ветвления, разработанную для выпуска проекта. Этот рабочий процесс не добавляет каких-либо новых концепций или команд помимо того, что требуется для рабочего процесса Feature Branch. Вместо этого он назначает очень конкретные роли различным ветвям и определяет, как и когда они должны взаимодействовать.

Forking Workflow
Рабочий процесс Forking отличается от других рабочих процессов. Вместо того чтобы использовать один серверный репозиторий в качестве «центральной» кодовой базы, он предоставляет каждому разработчику серверный репозиторий. Это означает, что у каждого участника есть не один, а два репозитория Git: частный локальный и общедоступный серверный.

Рекомендации:

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

Выводы:
Мы с вами рассмотрели работу системы git и работу с удаленными репозиториями.
В некоторой степени коснулись вопроса установки и конфигурации git, регистрации удаленного репозитория на примере GitHub. Применения git как локально, так и удаленно. А также некоторые моменты организации рабочего процесса. В одной статье невозможно рассказать обо всем. Вы можете продолжить обучение изучая материалы документации и публикации других авторов. Что меня по настоящему восхищает в git, так это проектирование и реализация хорошей экосистемы.

.gitignore. Отправка только тех файлов в репозиторий, которые необходимы
Вам может понадобится чтобы в ваш репозиторий не попадали лишние файлы.
Вы можете редактировать файл .gitignore вручную.
Для автоматического исключения некоторых файлов проекта вы можете скачать плагин для вашего IDE. Например для NetBeans 10 вы можете скачать и установить плагин с официального сайта netbeans:
plugins.netbeans.org/plugin/50356/gitignore-io
Владелец плагина: junichi11
Лицензия: Apache License, Version 2.0

Как установить:
1. Скачиваем файл в папку на локальном диске
2. Открываем IDE NetBeans
3. Tools/Plugin/Downloaded/Add Plugins
4. Указываем путь к плагину на вашем локальном компьютере.
5. Перезапуск IDE

Для IDE Intellij Idea вы можете скачать плагин «Add to gitignore»
plugins.jetbrains.com/plugin/7495—ignore

1.Переходим на сайт с плагином
2. Выбираем вашу версию IDE
3. Читаем инструкцию.
4. Скачиваем и устанавливаем

Вы можете установить плагин из IDE:
Preferences > Plugins > Browse repositories… > Search for «.ignore» > Install Plugin
После установки «Restart Idea».

git update-git-for-windows #обновить git для windows

Дополнительные ресурсы:
Онлайн книга по Git >>>
10 полезных Git команд, которые облегчат работу >>>
Отладка кода с Git: 3 инструмента для поиска ошибок >>>
Магия Git. Студенты. Stanford >>>
Здесь, на хабре есть замечательная публикация о Git автора jsirex, «Ежедневная работа с Git»

Как вы знаете от версии к версии в программы вносятся изменения.
Какие изменения были сделаны для версии git 2.0: >>>

Здесь еще следует немного рассказать о безопасности использования git и то что относится к использованию различных UI для git.

Продолжение, уточнение следует…

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

Git — Book

2nd Edition (2014)

Download Ebook

The entire Pro Git book, written by Scott Chacon and Ben Straub and published by Apress, is available here. All content is licensed under the Creative Commons Attribution Non Commercial Share Alike 3.0 license. Print versions of the book are available on Amazon.com.>

1. 1. 1.1 О системе контроля версий
   2. 1.2 Краткая история Git
   3. 1.3 Основы Git
   4. 1.4 Командная строка
   5. 1.5 Установка Git
   6. 1.6 Первоначальная настройка Git
   7. 1.7 Как получить помощь?
   8. 1.8 Заключение
2. 1. 2.1 Создание Git-репозитория
   2. 2.2 Запись изменений в репозиторий
   3. 2.3 Просмотр истории коммитов
   4. 2.4 Операции отмены
   5. 2.5 Работа с удалёнными репозиториями
   6. 2.6 Работа с метками
   7. 2.7 Псевдонимы в Git
   8. 2.8 Заключение
3. 1. 3.1 О ветвлении в двух словах
   2. 3.2

Как начать работать с GitHub: быстрый старт / Хабр

Распределенные системы контроля версий (DVCS) постепенно замещают собой централизованные. Если вы еще не используете одну из них — самое время попробовать.

В статье я постараюсь показать, как можно быстро начать экспериментировать с git, используя сайт github.com.

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

Итак, сайт github.com позиционируется как веб-сервис хостинга проектов с использованием системы контроля версий git, а также как социальная сеть для разработчиков. Пользователи могут создавать неограниченное число репозиториев, для каждого из которых предоставляется wiki, система issue tracking-а, есть возможность проводить code review и многое другое. GitHub на данный момент является самым популярным сервисом такого рода, обогнав Sourceforge и Google Code.

Для open-souce проектов использование сайта бесплатно. При необходимости иметь приватные репозитории, есть возможность перейти на платный тарифный план:

Начнем с регистрации. Идем по ссылке github.com/signup/free и вводим свои данные.
После регистрации мы попадаем на Dashboard нашего аккаунта:

Сейчас у нас нет ни одного репозитория, и мы можем либо создать новый репозиторий, либо ответвиться (fork) от уже существующего чужого репозитория и вести собственную ветку разработки. Затем, при желании, свои изменения можно предложить автору исходного репозитория (Pull request).

Но для начала установим git и настроим его для работы с сайтом.

Если вы работаете в Windows, качаем и устанавливаем msysgit. Это консольная версия git для Windows (далее расказ будет вестись на примере этой ОС).
Инструкция для MacOS X (eng)
Инструкция для Linux (eng)
Проблем возникнуть не должно, просто везде жмем Next. После установки выбираем в контекстном меню Проводника Git Bash:

или через Git Bash.lnk в папке с установленой программой:

Прописываем в консоли свои данные и настройки переносов строк:
git config --global user.name "ваше имя"
git config --global user.email "ваша почта"
git config --global core.autocrlf true
git config --global core.safecrlf true

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

Для тех, кто предпочитает gui — для Windows существует несколько таких инструментов для работы с git. Два основных — это SmartGit (кроссплатформенный) и TortoiseGit. Оба неплохие, и какой использовать — дело вкуса. Я опишу работу с TortoiseGit.
Для маков выбор giu тоже имеется.

• официальный клиент от GitHub — на мой взгляд пока достаточно сыроват.
• GitX — лично мне не приглянулся
• GitBox — наиболее следует mac-way, очень рекомендую попробовать именно его

Качаем по ссылке code.google.com/p/tortoisegit/downloads/list. При установке везде жмем Next.

Теперь возвращаемся к github и создадим новый репозиторий. Находясь на Dashboard, жмем New Repository (https://github.com/repositories/new), вводим данные и жмем Create Repository.

GitHub позволяет работать с репозиториями тремя способами: SSH, HTTP и Git Read-Only, соответственно предоставляя ссылки трех видов для нашего репозитория:
1. [email protected]:habrauser/Hello-world.git
2. [email protected]/habrauser/Hello-world.git
3. git://github.com/habrauser/Hello-world.git

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

Если же мы захотим внести изменения в репозиторий на github, нужно пользоваться HTTP или SSH.
Работа по http никаких трудностей не вызывает, в нужный момент просто используется пароль учетной записи на github.

Чтобы использовать SSH, нам нужно создать специальную пару ключей: публичный и приватный. Публичный будет размещен в настройках аккаунта на github, а приватный сохранен на локальной машине.

Для генерации ключей, можно воспользоваться инструментом ssh-keygen, который идет в комплекте с git (описание этого способа можно почитать тут). Мы же будем использовать PuTTY (а точнее небольшую программку puttygen, входящую в его состав). PuTTY — это такой клиент для удаленного доступа, в том числе и с использованием SSH.

Качаем последнюю версию с официального сайта (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html). Кстати, puttygen более старой версии (2007 год) идет в составе TortoiseGit.

После установки PuTTY, запускаем puttygen из папки с установленной программой:

Жмем Generate, двигаем некоторое время курсором мыши, для получения случайных данных, необходимых алгоритму

Вводим пароль, защищающий наш приватный ключ в поле Key passphrase, вводим подтверждение, жмем Save private key, сохраняем.

Далее копируем публичный ключ в формате OpenSSH из текстовой области «Public key for pasting…» и идем в настройки нашего аккаунта на github (Account Settings) в раздел SSH Public Keys:

жмем Add another public Key, вставляем наш публичный ключ:

нажимаем Add key. Все, теперь мы готовы работать с github по ssh. Попробуем забрать наш пустой рерозиторий на локальную машину с использованием TortioшseGit. В контекстном меню проводника выбираем Git Clone…

В поле Url вставляем SSH-адрес нашего репозитория, в поле Load Putty Key указываем путь к нашему приватному ключу, жмем OK.

Pageant запросит у наc пароль для приватного ключа (потом этого делать не потребуется)

Pageant — это агент SSH-аутентификации в составе PuTTY, он позволяет управлять закрытыми ключами.
В трее висит его значек:

Репозиторий успешно склонирован на локальную машину

Теперь попробуем изменить локальный репозиторий и отправить изменения на github. Добавим в локальный репозиторий файл README (файл с именем README обрабатывается github специальным образом — его содержимое будет отображаться в качестве описания репозитория на соответствующей странице)

Закоммитим изменения в локальный репозиторий

и синхронизируем его с репозиторием на github:

нажимаем Push

Теперь зайдя на страницу нашего репозитория мы увидим следующее:

Для каждого репозитория сайт предлагает wiki:

а также простую систему issue tracking-a:

кстати, для тех, кто использует в работе Eclipсe — есть соответствующий mylyn-коннектор для github:

и плагин EGit:

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

Резюмируя хочется сказать, что если вы начинающий разработчик, планирующий начать пользоваться системами контроля версий, или же более опытный и присматривающийся к распределенным VCS, но не знающий как начать, то есть смысл попробовать git, используя такой замечательный инструмент как github.com.

Полезные ссылки

Для работы с git:
code.google.com/p/msysgit git для windows
www.syntevo.com/smartgit/index.html SmartGit
code.google.com/p/tortoisegit TortoiseGit
http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY

Про git на русском:
habrahabr.ru/blogs/Git/106912 «Удачная модель ветвления для git» — перевод хорошей англоязычной статьи
githowto.com интерактивный курс по работе с git из консоли
habrahabr.ru/blogs/Git/106912 «Почему git» + обсуждение
habrahabr.ru/blogs/development/68341 «Git для переходящих с SVN» + обсуждение
habrahabr.ru/blogs/Git/75990 «Командная работа в git» + обсуждение
progit.org/book/ru русский перевод книги «Pro Git» (переведено не до конца)
habrahabr.ru/blogs/Git/123111 инструкция-шпаргалка для начинающих
los-t.livejournal.com/tag/git%20guts цикл постов «внутренности git»
lib.custis.ru/%D0%9B%D0%B8%D0%BD%D1%83%D1%81_%D0%A2%D0%BE%D1%80%D0%B2%D0%B0%D0%BB%D1%8C%D0%B4%D1%81_%D0%BE_GIT_%D0%BD%D0%B0_Google_Talks Линус Торвальдс о git
habrahabr.ru/blogs/Git/80909 книга «Волшебство git»

Про git на английском:
книги

видео
другое

Как работает Git / Хабр

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

Эссе концентрируется на структуре графа, на которой основан Git, и на том, как свойства этого графа определяют поведение Git. Изучая основы, вы строите своё представление на достоверной информации, а не на гипотезах, полученных из экспериментов с API. Правильная модель позволит вам лучше понять, что сделал Git, что он делает и что он собирается сделать.

Текст разбит на серии команд, работающих с единым проектом. Иногда встречаются наблюдения по поводу структуры данных графа, лежащего в основе Git. Наблюдения иллюстрируют свойство графа и поведение, основанное на нём.

После прочтения для ещё более глубокого погружения можно обратиться к обильно комментируемому исходному коду моей реализации Git на JavaScript.

Создание проекта

~ $ mkdir alpha
~ $ cd alpha

Пользователь создаёт директорию alpha

~/alpha $ mkdir data
~/alpha $ printf 'a' > data/letter.txt

Он перемещается в эту директорию и создаёт директорию data. Внутри он создаёт файл letter.txt с содержимым «а». Директория alpha выглядит так:

alpha
└── data
    └── letter.txt

Инициализируем репозиторий

~/alpha $ git init
          Initialized empty Git repository

git init вносит текущую директорию в Git-репозиторий. Для этого он создаёт директорию .git и создаёт в ней несколько файлов. Они определяют всю конфигурацию Git и историю проекта. Это обычные файлы – никакой магии. Пользователь может их читать и редактировать. То есть – пользователь может читать и редактировать историю проекта так же просто, как файлы самого проекта.

Теперь директория alpha выглядит так:

alpha
├── data
|   └── letter.txt
└── .git
    ├── objects
    etc...

Директория .git с её содержимым относится с Git. Все остальные файлы называются рабочей копией и принадлежат пользователю.

Добавляем файлы

~/alpha $ git add data/letter.txt

Пользователь запускает git add на data/letter.txt. Происходят две вещи.

Во-первых, создаётся новый блоб-файл в директории .git/objects/. Он содержит сжатое содержимое data/letter.txt. Его имя – сгенерированный хэш на основе содержимого. К примеру, Git делает хэш от а и получает 2e65efe2a145dda7ee51d1741299f848e5bf752e. Первые два символа хэша используются для имени директории в базе объектов: .git/objects/2e/. Остаток хэша – это имя блоб-файла, содержащего внутренности добавленного файла: .git/objects/2e/65efe2a145dda7ee51d1741299f848e5bf752e.

Заметьте, что простое добавление файла в Git приводит к сохранению его содержимого в директории objects. Оно будет храниться там, если пользователь удалит data/letter.txt из рабочей копии.

Во-вторых, git add добавляет файл в индекс. Индекс – это список, содержащий все файлы, за которыми Git было наказано следить. Он хранится в .git/index. Каждая строка даёт в соответствие отслеживаемому файлу хэш его содержимого и время добавления. Вот таким получается содержимое индекса после команды git add:

data/letter.txt 2e65efe2a145dda7ee51d1741299f848e5bf752e

Пользователь создаёт файл data/number.txt содержащий 1234.

~/alpha $ printf '1234' > data/number.txt

Рабочая копия выглядит так:

alpha
└── data
    └── letter.txt
    └── number.txt

Пользователь добавляет файл в Git.

~/alpha $ git add data

Команда git add создаёт блоб-файл, в котором хранится содержимое data/number.txt. Он добавляет в индекс запись для data/number.txt, указывающую на блоб. Вот содержимое индекса после повторного запуска git add:

data/letter.txt 2e65efe2a145dda7ee51d1741299f848e5bf752e
data/number.txt 274c0052dd5408f8ae2bc8440029ff67d79bc5c3

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

~/alpha $ printf '1' > data/number.txt
~/alpha $ git add data

Когда пользователь создал data/number.txt, он хотел написать 1, а не 1234. Он вносит изменение и снова добавляет файл к индексу. Эта команда создаёт новый блоб с новым содержимым. Она обновляет запись в индексе для data/number.txt с указанием на новый блоб.

Делаем коммит

~/alpha $ git commit -m 'a1'
          [master (root-commit) 774b54a] a1

Пользователь делает коммит a1. Git выводит данные о нём. Мы вскоре объясним их.

У команды commit есть три шага. Она создаёт граф, представляющий содержимое версии проекта, которую коммитят. Она создаёт объект коммита. Она направляет текущую ветку на новый объект коммита.

Создание графа

Git запоминает текущее состояние проекта, создавая древовидный граф из индекса. Этот граф записывает расположение и содержимое каждого файла в проекте.

Граф состоит из двух типов объектов: блобы и деревья. Блобы сохраняются через git add. Они представляют содержимое файлов. Деревья сохраняются при коммите. Дерево представляет директорию в рабочей копии. Ниже приведён объект дерева, записавший содержимое директории data при новом коммите.

100664 blob 2e65efe2a145dda7ee51d1741299f848e5bf752e letter.txt
100664 blob 56a6051ca2b02b04ef92d5150c9ef600403cb1de number.txt

Первая строка записывает всё необходимое для воспроизводства data/letter.txt. Первая часть хранит права доступа к файлу. Вторая – что содержимое файла хранится в блобе, а не в дереве. Третья – хэш блоба. Четвёртая – имя файла.

Вторая строчка тем же образом относится к data/number.txt.

Ниже указан объект-дерево для alpha, корневой директории проекта:

040000 tree 0eed1217a2947f4930583229987d90fe5e8e0b74 data

Единственная строка указывает на дерево data.

В приведённом графе дерево root указывает на дерево data. Дерево data указывает на блобы для data/letter.txt и data/number.txt.

Создание объекта коммита

git commit создаёт объект коммита после создания графа. Объект коммита – это ещё один текстовый файл в .git/objects/:

tree ffe298c3ce8bb07326f888907996eaa48d266db4
author Mary Rose Cook <[email protected]> 1424798436 -0500
committer Mary Rose Cook <[email protected]> 1424798436 -0500

a1

Первая строка указывает на дерево графа. Хэш – для объекта дерева, представляющего корень рабочей копии. То бишь, директории alpha. Последняя строчка – комментарий коммита.

Направить текущую ветку на новый коммит

Наконец, команда коммита направляет текущую ветку на новый объект коммита.

Какая у нас текущая ветка? Git идёт в файл HEAD в .git/HEAD и видит:

ref: refs/heads/master

Это значит, что HEAD указывает на master. master – текущая ветка.

HEAD и master – это ссылки. Ссылка – это метка, используемая Git, или пользователем, для идентификации определённого коммита.

Файла, представляющего ссылку master, не существует, поскольку это первый коммит в репозитории. Git создаёт файл в .git/refs/heads/master и задаёт его содержимое – хэш объекта коммит:

74ac3ad9cde0b265d2b4f1c778b283a6e2ffbafd

(Если вы параллельно чтению вбиваете в Git команды, ваш хэш a1 будет отличаться от моего. Хэш объектов содержимого – блобов и деревьев – всегда получаются теми же. А коммитов – нет, потому что они учитывают даты и имена создателей).

Добавим в граф Git HEAD и master:

HEAD указывает на master, как и до коммита. Но теперь master существует и указывает на новый объект коммита.

Делаем не первый коммит

Ниже приведён граф после коммита a1. Включены рабочая копия и индекс.

Заметьте, что у рабочей копии, индекса и коммита одинаковое содержимое data/letter.txt и data/number.txt. Индекс и HEAD используют хэши для указания на блобы, но содержимое рабочей копии хранится в виде текста в другом месте.

~/alpha $ printf '2' > data/number.txt

Пользователь меняет содержимое data/number.txt на 2. Это обновляет рабочую копию, но оставляет индекс и HEAD без изменений.

~/alpha $ git add data/number.txt

Пользователь добавляет файл в Git. Это добавляет блоб, содержащий 2, в директорию objects. Указатель записи индекса для data/number.txt указывает на новый блоб.

~/alpha $ git commit -m 'a2'
          [master f0af7e6] a2

Пользователь делает коммит. Шаги у него такие же, как и раньше.

Во-первых, создаётся новый древовидный граф для представления содержимого индекса.

Запись в индексе для data/number.txt изменилась. Старое дерево data уже не отражает проиндексированное состояние директории data. Нужно создать новый объект-дерево data.

100664 blob 2e65efe2a145dda7ee51d1741299f848e5bf752e letter.txt
100664 blob d8263ee9860594d2806b0dfd1bfd17528b0ba2a4 number.txt

Хэш у нового объекта отличается от старого дерева data. Нужно создать новое дерево root для записи этого хэша.

040000 tree 40b0318811470aaacc577485777d7a6780e51f0b data

Во-вторых, создаётся новый объект коммита.

tree ce72afb5ff229a39f6cce47b00d1b0ed60fe3556
parent 774b54a193d6cfdd081e581a007d2e11f784b9fe
author Mary Rose Cook <[email protected]> 1424813101 -0500
committer Mary Rose Cook <[email protected]> 1424813101 -0500

a2

Первая строка объекта коммита указывает на новый объект root. Вторая строка указывает на a1: родительский коммит. Для поиска родительского коммита Git идёт в HEAD, проходит до master и находит хэш коммита a1.

В третьих, содержимое файла-ветви master меняется на хэш нового коммита.

Коммит a2
Граф Git без рабочей копии и индекса

Свойства графа:

• Содержимое хранится в виде дерева объектов. Это значит, что в базе хранятся только изменения. Взгляните на граф сверху. Коммит а2 повторно использует блоб, сделанный до коммита а1. Точно так же, если вся директория от коммита до коммита не меняется, неё дерево и все блобы и нижележащие деревья можно использовать повторно. Обычно изменения между коммитами небольшие. Это значит, что Git может хранить большие истории коммитов, занимая немного места.

• У каждого коммита есть предок. Это значит, что в репозитории можно хранить историю проекта.

• Ссылки – входные точки для той или иной истории коммита. Это значит, что коммитам можно давать осмысленные имена. Пользователь организовывает работу в виде родословной, осмысленной для своего проекта, с ссылками типа fix-for-bug-376. Git использует символьные ссылки вроде HEAD, MERGE_HEAD и FETCH_HEAD для поддержки команды редактирования истории коммитов.

• Узлы в директории objects/ неизменны. Это значит, что содержимое редактируется, но не удаляется. Каждый кусочек содержимого, добавленный когда-либо, каждый сделанный коммит хранится где-то в директории objects.

• Ссылки изменяемы. Значит, смысл ссылки может измениться. Коммит, на который указывает master, может быть наилучшей версией проекта на текущий момент, но вскоре его может сменить новый коммит.

• Рабочая копия и коммиты, на которые указывают ссылки, доступны сразу. Другие коммиты – нет. Это значит, что недавнюю историю легче вызвать, но и меняется она чаще. Можно сказать, что память Git постоянно исчезает, и её надо стимулировать всё более жёсткими тычками.

Рабочую копию легче всего вызвать из истории, поскольку она находится в корне репозитория. Её вызов даже не требует команды Git. Но также это и самая непостоянная точка в истории. Пользователь может сделать десяток версий файла, но Git не запишет ни одну из них, пока они не добавлены.

Коммит, на который указывает HEAD, очень легко вызвать. Он находится на конце подтверждённой ветви. Чтобы просмотреть его содержимое, пользователь может просто сохранить и затем изучить рабочую копию. И в то же время, HEAD – самая часто изменяющаяся ссылка.

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

Сложно вызвать коммит, на который не указывают ссылки. Чем дальше пользователь уходит от ссылки, тем тяжелее ему воссоздать смысл коммита. Но чем дальше в прошлое он идёт, тем меньше вероятность, что кто-либо изменил историю с момента их предыдущего просмотра.

Подтверждение (check out) коммита

~/alpha $ git checkout 37888c2
          You are in 'detached HEAD' state...

Пользователь подтверждает коммит а2, используя его хэш. (Если вы запускаете эти команды, то данная команда у вас не сработает. Используйте git log, чтобы выяснить хэш вашего коммита а2).

Подтверждение состоит из четырёх шагов.

Во-первых, Git получает коммит а2 и граф, на который тот указывает.

Во-вторых, он делает записи о файлах в графе в рабочей копии. В результате изменений не происходит. В рабочей копии уже есть содержимое графа, поскольку HEAD уже указывал на коммит а2 через master.

В-третьих, Git делает записи о файлах в граф в индексе. Тут тоже изменений не происходит. В индексе уже содержится коммит а2.

В-четвёртых, содержимому HEAD присваивается хэш коммита а2:

f0af7e62679e144bb28c627ee3e8f7bdb235eee9

Запись хэша в HEAD приводит репозиторий в состоянии с отделённым HEAD. Обратите внимание на графе ниже, что HEAD указывает непосредственно на коммит а2, а не на master.

~/alpha $ printf '3' > data/number.txt
~/alpha $ git add data/number.txt
~/alpha $ git commit -m 'a3'
          [detached HEAD 3645a0e] a3

Пользователь записывает в содержимое data/number.txt значение 3 и коммитит изменение. Git идёт к HEAD для получения родителя коммита а3. Вместо того, чтобы найти и последовать по ссылке на ветвь, он находит и возвращает хэш коммита а2.

Git обновляет HEAD, чтобы он указывал на хэш нового коммита а3. Репозиторий по-прежнему находится в состоянии с отделённым HEAD. Он не на ветви, поскольку ни один коммит не указывает ни на а3, ни на любой из его потомков. Его легко потерять.

Далее мы будем опускать деревья и блобы из диаграмм графов.

Создать ответвление (branch)

~/alpha $ git branch deputy

Пользователь создаёт новую ветвь под названием deputy. В результате появляется новый файл в .git/refs/heads/deputy, содержащий хэш, на который указывает HEAD: хэш коммита а3.

Ветви – это только ссылки, а ссылки – это только файлы. Это значит, что ветви Git весят очень немного.

Создание ветви deputy размещает новый коммит а3 на ответвлении. HEAD всё ещё отделён, поскольку всё ещё показывает непосредственно на коммит.

Подтвердить ответвление

~/alpha $ git checkout master
          Switched to branch 'master'

Пользователь подтверждает ответвление master.

Во-первых, Git получает коммит а2, на который указывает master, и получает граф, на который указывает коммит.

Во-вторых, Git вносит файловые записи в граф в файлы рабочей копии. Это меняет контент data/number.txt на 2.

В-третьих, Git вносит файловые записи в граф индекса. Это обновляет вхождение для data/number.txt на хэш блоба 2.

В-четвёртых, Git направляет HEAD на master, меняя его содержимое с хэша на

ref: refs/heads/master

Подтвердить ветвь, несовместимую с рабочей копией

~/alpha $ printf '789' > data/number.txt
~/alpha $ git checkout deputy
          Your changes to these files would be overwritten
          by checkout:
            data/number.txt
          Commit your changes or stash them before you
          switch branches.

Пользователь случайно присваивает содержимому data/number.txt значение 789. Он пытается подтвердить deputy. Git препятствует подтверждению.

HEAD указывает на master, указывающий на a2, где в data/number.txt записано 2. deputy указывает на a3, где в data/number.txt записано 3. В версии рабочей копии для data/number.txt записано 789. Все эти версии различны, и разницу нужно как-то устранить.

Git может заменить версию рабочей копии версией из подтверждаемого коммита. Но он всеми силами избегает потери данных.

Git может объединить версию рабочей копии с подтверждаемой версией. Но это сложно.

Поэтому Git отклоняет подтверждение.

~/alpha $ printf '2' > data/number.txt
~/alpha $ git checkout deputy
          Switched to branch 'deputy'

Пользователь замечает, что он случайно отредактировал data/number.txt и присваивает ему обратно 2. Затем он успешно подтверждает deputy.

Объединение с предком

~/alpha $ git merge master
          Already up-to-date.

Пользователь включает master в deputy. Объединение двух ветвей означает объединение двух коммитов. Первый коммит – тот, на который указывает deputy: принимающий. Второй коммит – тот, на который указывает master: дающий. Для объединения Git ничего не делает. Он сообщает, что он уже «Already up-to-date».

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

Объединение с потомком

~/alpha $ git checkout master
          Switched to branch 'master'

Пользователь подтверждает master.

~/alpha $ git merge deputy
          Fast-forward

Он включает deputy в master. Git обнаруживает, что коммит принимающего, а2, является предком коммита дающего, а3. Он может сделать объединение с быстрой перемоткой вперёд.

Он берёт коммит дающего и граф, на который он указывает. Он вносит файловые записи в графы рабочей копии и индекса. Затем он «перематывает» master, чтобы тот указывал на а3.

Серия коммитов на графе интерпретируется как серия изменений содержимого репозитория. Это значит, что при объединении, если дающий является потомком принимающего, история не меняется. Уже существует последовательность коммитов, описывающих нужные изменения: последовательность коммитов между принимающим и дающим. Но, хотя история Git не меняется, граф Git меняется. Конкретная ссылка, на которую указывает HEAD, обновляется, чтобы указывать на коммит дающего.

Объединить два коммита из разных родословных

~/alpha $ printf '4' > data/number.txt
~/alpha $ git add data/number.txt
~/alpha $ git commit -m 'a4'
          [master 7b7bd9a] a4

Пользователь записывает 4 в содержимое number.txt и коммитит изменение в master.

~/alpha $ git checkout deputy
          Switched to branch 'deputy'
~/alpha $ printf 'b' > data/letter.txt
~/alpha $ git add data/letter.txt
~/alpha $ git commit -m 'b3'
          [deputy 982dffb] b3

Пользователь подтверждает deputy. Он записывает «b» в содержимое data/letter.txt и коммитит изменение в deputy.

У коммитов могут быть общие родители. Это значит, что в истории коммитов можно создавать новые родословные.

У коммитов может быть несколько родителей. Это значит, что разные родословные можно объединить коммитом с двумя родителями: объединяющим коммитом.

~/alpha $ git merge master -m 'b4'
          Merge made by the 'recursive' strategy.

Пользователь объединяет master с deputy.

Git обнаруживает, что принимающий, b3, и дающий, a4, находятся в разных родословных. Он выполняет объединяющий коммит. У этого процесса восемь шагов.

1. Git записывает хэш дающего коммита в файл alpha/.git/MERGE_HEAD. Наличие этого файла сообщает Git, что он находится в процессе объединения.

2. Во-вторых, Git находит базовый коммит: самый новый предок, общий для дающего и принимающего коммитов.

У коммитов есть родители. Это значит, что можно найти точку, в которой разделились две родословных. Git отслеживает цепочку назад от b3, чтобы найти всех его предков, и назад от a4 с той же целью. Он находит самого нового из их общих предков, а3. Это базовый коммит.

3. Git создают индексы для базового, дающего и принимающего коммита из их древовидных графов.

4. Git создаёт diff, объединяющий изменения, которые принимающий и дающий коммиты произвели с базовым. Этот diff – список путей файлов, указывающих на изменения: добавление, удаление, модификацию или конфликты.

Git получает список всех файлов, имеющихся в индексах базового коммита, получающего и дающего. Для каждого он сравнивает записи в индексах и решает, каким образом нужно менять файл. Он пишет соответствующую запись в diff. В нашем случае в diff попадают две записи.

Первая запись для data/letter.txt. Содержимое этого файла – «a» в базовом, «b» в получающем и «a» в дающем. Содержимое у базового и получающего различается. Но у базового и дающего – совпадает. Git видит, что содержимое изменено получающим, а не дающим. Запись в diff для data/letter.txt – это изменение, а не конфликт.

Вторая запись в diff – для data/number.txt. В этом случае, содержимое совпадает у базового и получающего, а у дающего оно другое. Запись в diff для data/number.txt — также изменение.

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

5. Изменения, описанные записями в diff, применяются к рабочей копии. Содержимому data/letter.txt присваивается значение b, а содержимому data/number.txt – 4.

6. Изменения, описанные записями в diff, применяются к индексу. Запись, относящаяся к data/letter.txt, указывает на блоб b, а запись для data/number.txt – на блоб 4.

7. Подтверждается обновлённый индекс:

tree 20294508aea3fb6f05fcc49adaecc2e6d60f7e7d
parent 982dffb20f8d6a25a8554cc8d765fb9f3ff1333b
parent 7b7bd9a5253f47360d5787095afc5ba56591bfe7
author Mary Rose Cook <[email protected]> 1425596551 -0500
committer Mary Rose Cook <[email protected]> 1425596551 -0500

b4

Обратите внимание, что у коммита два родителя.

8. Git направляет текущую ветвь, deputy, на новый коммит.

Объединение двух коммитов из разных родословных, изменяющих один и тот же файл

~/alpha $ git checkout master
          Switched to branch 'master'
~/alpha $ git merge deputy
          Fast-forward

Пользователь подтверждает master. Он объединяет deputy и master. Это приводит к перемотке master до коммита b4. Теперь master и deputy указывают на один и тот же коммит.

~/alpha $ git checkout deputy
          Switched to branch 'deputy'
~/alpha $ printf '5' > data/number.txt
~/alpha $ git add data/number.txt
~/alpha $ git commit -m 'b5'
          [deputy bd797c2] b5

Пользователь подтверждает deputy. Он устанавливает содержимое data/number.txt в 5 и подтверждает изменение в deputy.

~/alpha $ git checkout master
          Switched to branch 'master'
~/alpha $ printf '6' > data/number.txt
~/alpha $ git add data/number.txt
~/alpha $ git commit -m 'b6'
          [master 4c3ce18] b6

Пользователь подтверждает master. Он устанавливает содержимое data/number.txt в 6 и подтверждает изменение в master.

~/alpha $ git merge deputy
          CONFLICT in data/number.txt
          Automatic merge failed; fix conflicts and
          commit the result.

Пользователь объединяет deputy и master. Выявляется конфликт и объединение приостанавливается. Процесс объединения с конфликтом делает те же шесть первых шагов, что и процесс объединения без конфликта: определить .git/MERGE_HEAD, найти базовый коммит, создать индексы для базового, принимающего и дающего коммитов, создать diff, обновить рабочую копию и обновить индекс. Из-за конфликта седьмой шаг с коммитом и восьмой с обновлением ссылки не выполняются. Пройдём по ним заново и посмотрим, что получается.

1. Git записывает хэш дающего коммита в файл .git/MERGE_HEAD.

2. Git находит базовый коммит, b4.

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

4. Git генерирует diff, комбинирующий изменения базового коммита, произведённые получающим и дающим коммитами. Этот diff – список путей к файлам, указывающим на изменения: добавление, удаление, модификацию или конфликт.

В данном случае diff содержит только одну запись: data/number.txt. Она отмечена как конфликт, поскольку содержимое data/number.txt отличается в дающем, принимающем и базовом коммитах.

5. Изменения, определяемые записями в diff, применяются к рабочей копии. В области конфликта Git выводит обе версии в файл рабочей копии. Содержимое файла ata/number.txt становится следующим:

<<<<<<< HEAD
6
=======
5
>>>>>>> deputy

6. Изменения, определённые записями в diff, применяются к индексу. Записи в индексе имеют уникальный идентификатор в виде комбинации пути к файлу и этапа. У записи файла без конфликта этап равен 0. Перед объединением индекс выглядел так, где нули – это номера этапов:

0 data/letter.txt 63d8dbd40c23542e740659a7168a0ce3138ea748
0 data/number.txt 62f9457511f879886bb7728c986fe10b0ece6bcb

После записи diff в индекс тот выглядит уже так:

0 data/letter.txt 63d8dbd40c23542e740659a7168a0ce3138ea748
1 data/number.txt bf0d87ab1b2b0ec1a11a3973d2845b42413d9767
2 data/number.txt 62f9457511f879886bb7728c986fe10b0ece6bcb
3 data/number.txt 7813681f5b41c028345ca62a2be376bae70b7f61

Запись data/letter.txt на этапе 0 такая же, какая и была до объединения. Запись для data/number.txt с этапом 0 исчезла. Вместо неё появились три новых. У записи с этапом 1 хэш от базового содержимого data/number.txt. У записи с этапом 3 хэш от содержимого дающего data/number.txt. Присутствие трёх записей говорит Git, что для data/number.txt возник конфликт.

Объединение приостанавливается.

~/alpha $ printf '11' > data/number.txt
~/alpha $ git add data/number.txt

Пользователь интегрирует содержимое двух конфликтующих версий, устанавливая содержимое data/number.txt равным 11. Он добавляет файл в индекс. Git добавляет блоб, содержащий 11. Добавление конфликтного файла говорит Git о том, что конфликт решён. Git удаляет вхождения data/number.txt для этапов 1, 2 и 3 из индекса. Он добавляет запись для data/number.txt на этапе 0 с хэшем от нового блоба. Теперь индекс содержит записи:

0 data/letter.txt 63d8dbd40c23542e740659a7168a0ce3138ea748
0 data/number.txt 9d607966b721abde8931ddd052181fae905db503

~/alpha $ git commit -m 'b11'
          [master 251a513] b11

7. Пользователь коммитит. Git видит в репозитории .git/MERGE_HEAD, что говорит ему о том, что объединение находится в процессе. Он проверяет индекс и не обнаруживает конфликтов. Он создаёт новый коммит, b11, для записи содержимого разрешённого объединения. Он удаляет файл .git/MERGE_HEAD. Это и завершает объединение.

8. Git направляет текущую ветвь, master, на новый коммит.

Удаление файла

Диаграмма для графа Git включает историю коммитов, деревья и блобы последнего коммита, рабочую копию и индекс:

~/alpha $ git rm data/letter.txt
          rm 'data/letter.txt'

Пользователь указывает Git удалить data/letter.txt. Файл удаляется из рабочей копии. Из индекса удаляется запись.

~/alpha $ git commit -m '11'
          [master d14c7d2] 11

Пользователь делает коммит. Как обычно при коммите, Git строит граф, представляющий содержимое индекса. data/letter.txt не включён в граф, поскольку его нет в индексе.

Копировать репозиторий

~/alpha $ cd ..
      ~ $ cp -R alpha bravo

Пользователь копирует содержимое репозитория alpha/ в директорию bravo/. Это приводит к следующей структуре:

~
├── alpha
|   └── data
|       └── number.txt
└── bravo
    └── data
        └── number.txt

Теперь в директории bravo есть новый граф Git:

Связать репозиторий с другим репозиторием

      ~ $ cd alpha
~/alpha $ git remote add bravo ../bravo

Пользователь возвращается в репозиторий alpha. Он назначает bravo удалённым репозиторием для alpha. Это добавляет несколько строк в файл alpha/.git/config:

[remote "bravo"]
	url = ../bravo/

Строки говорят, что существует удалённый репозиторий bravo в директории ../bravo.

Получить ветвь с удалённого репозитория

~/alpha $ cd ../bravo
~/bravo $ printf '12' > data/number.txt
~/bravo $ git add data/number.txt
~/bravo $ git commit -m '12'
          [master 94cd04d] 12

Пользователь переходит к репозиторию bravo. Он присваивает содержимому data/number.txt значение 12 и коммитит изменение в master на bravo.

~/bravo $ cd ../alpha
~/alpha $ git fetch bravo master
          Unpacking objects: 100%
          From ../bravo
            * branch master -> FETCH_HEAD

Пользователь переходит в репозиторий alpha. Он копирует master из bravo в alpha. У этого процесса четыре шага.

1. Git получает хэш коммита, на который в bravo указывает master. Это хэш коммита 12.

2. Git составляет список всех объектов, от которых зависит коммит 12: сам объект коммита, объекты в его графе, коммиты предка коммита 12, и объекты из их графов. Он удаляет из этого списка все объекты, которые уже есть в базе alpha. Остальное он копирует в alpha/.git/objects/.

3. Содержимому конкретного файла ссылки в alpha/.git/refs/remotes/bravo/master присваивается хэш коммита 12.

4. Содержимое alpha/.git/FETCH_HEAD становится следующим:

94cd04d93ae88a1f53a4646532b1e8cdfbc0977f branch 'master' of ../bravo

Это значит, что самая последняя команда fetch достала коммит 12 из master с bravo.

Объекты можно копировать. Это значит, что у разных репозиториев может быть общая история.

Репозитории могут хранить ссылки на удалённые ветви типа alpha/.git/refs/remotes/bravo/master. Это значит, что репозиторий может локально записывать состояние ветви удалённого репозитория. Он корректен во время его копирования, но станет устаревшим в случае изменения удалённой ветви.

Объединение FETCH_HEAD

~/alpha $ git merge FETCH_HEAD
          Updating d14c7d2..94cd04d
          Fast-forward

Пользователь объединяет FETCH_HEAD. FETCH_HEAD – это просто ещё одна ссылка. Она указывает на коммит 12, дающий. HEAD указывает на коммит 11, принимающий. Git делает объединение-перемотку и направляет master на коммит 12.

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

~/alpha $ git pull bravo master
          Already up-to-date.

Пользователь переносит master из bravo в alpha. Pull – это сокращение для «скопировать и объединить FETCH_HEAD». Git выполняет обе команды и сообщает, что master «Already up-to-date».

Клонировать репозиторий

~/alpha $ cd ..
      ~ $ git clone alpha charlie
          Cloning into 'charlie'

Пользователь переезжает в верхний каталог. Он клонирует alpha в charlie. Клонирование приводит к результатам, сходным с командой cp, которую пользователь выполнил для создания репозитория bravo. Git создаёт новую директорию charlie. Он инициализирует charlie в качестве репозитория, добавляет alpha в качестве удалённого под именем origin, получает origin и объединяет FETCH_HEAD.

Разместить (push) ветвь на подтверждённой ветви на удалённом репозитории

      ~ $ cd alpha
~/alpha $ printf '13' > data/number.txt
~/alpha $ git add data/number.txt
~/alpha $ git commit -m '13'
          [master 3238468] 13

Пользователь возвращается в репозиторий alpha. Присваивает содержимому data/number.txt значение 13 и коммитит изменение в master на alpha.

~/alpha $ git remote add charlie ../charlie

Он назначает charlie удалённым репозиторием alpha.

~/alpha $ git push charlie master
          Writing objects: 100%
          remote error: refusing to update checked out
          branch: refs/heads/master because it will make
          the index and work tree inconsistent

Он размещает master на charlie. Все объекты, необходимые для коммита 13, копируются в charlie.

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

В этот момент пользователь может создать новую ветвь, объединить коммит 13 с ней и разместить эту ветвь на charlie. Но пользователям требуется репозиторий, на котором можно размещать, что угодно. Им нужен центральный репозиторий, на котором можно размещать, и с которого можно получать (pull), но на который напрямую никто не коммитит. Им нужно нечто типа удалённого GitHub. Им нужен чистый (bare) репозиторий.

Клонируем чистый (bare) репозиторий

~/alpha $ cd ..
      ~ $ git clone alpha delta --bare
          Cloning into bare repository 'delta'

Пользователь переходит в верхнюю директорию. Он создаёт клон delta в качестве чистого репозитория. Это обычный клон с двумя особенностями. Файл config говорит о том, что репозиторий чистый. И файлы, обычно хранящиеся в директории .git, хранятся в корне репозитория:

delta
├── HEAD
├── config
├── objects
└── refs

Разместить ветвь в чистом репозитории

      ~ $ cd alpha
~/alpha $ git remote add delta ../delta

Пользователь возвращается в репозиторий alpha. Он назначает delta удалённым репозиторием для alpha.

~/alpha $ printf '14' > data/number.txt
~/alpha $ git add data/number.txt
~/alpha $ git commit -m '14'
          [master cb51da8] 14

Он присваивает содержимому значение 14 и коммитит изменение в master на alpha.

~/alpha $ git push delta master
          Writing objects: 100%
          To ../delta
            3238468..cb51da8 master -> master

Он размещает master в delta. Размещение проходит в три этапа.

1. Все объекты, необходимые для коммита 14 на ветви master, копируются из alpha/.git/objects/ в delta/objects/.

2. delta/refs/heads/master обновляется до коммита 14.

3. alpha/.git/refs/remotes/delta/master направляют на коммит 14. В alpha находится актуальная запись состояния delta.

Итог

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

Чтобы узнать о Git ещё больше, изучайте директорию .git. Это не страшно. Загляните вовнутрь. Измените содержимое файлов и посмотрите, что произойдёт. Создайте коммит вручную. Попробуйте посмотреть, как сильно вы сможете сломать репозиторий. Затем почините его.

Git на практике / Хабр

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

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

Для начала давайте разберемся с тем что такое ветка и коммит.

Коммит

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

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

Git это распределенная система управления версиями. Это значит, что у каждого участника проекта есть своя копия репозитория, которая находиться в папке “.git”, которая расположена в корне проекта. Именно в этой папке хранятся все коммиты и другие объекты Git. Когда вы работаете с Git, он в свою очередь работает с этой папкой.

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

git init

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

git clone <url удаленного репозитория>

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

Существует несколько основных областей в которых находиться код.

• Рабочая директория – это файлы в корне проекта, тот код с которым вы работаете.
  
• Локальный репозиторий — она же директория “.git”. В ней хранятся коммиты и другие объекты.
• Удаленный репозиторий – тот самый репозиторий который считается общим, в который вы можете передать свои коммиты из локального репозитория, что бы остальные программисты могли их увидеть. Удаленных репозиториев может быть несколько, но обычно он бывает один.
• Есть еще одна область, с пониманием которой обычно бывают проблемы. Это так называемая область подготовленных изменений (staging area). Дело в том, что перед тем как включить какие-то изменения в коммит, нужно вначале отметить что именно вы хотите включить в этот коммит. В своей рабочей директории вы можете изменить несколько файлов, но в один конкретный коммит включать не все эти изменения.

В целом работа с гитом выглядит так: вы меняете файлы в своей рабочей директории, затем добавляете эти изменения в staging area используя команду

git add <имя/файла>

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

git commit –m “Комментарий к коммиту”

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

git push

После чего ваши коммиты уходят в удаленный репозиторий.

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

git pull

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

Код в рабочей области проекта образуется применением тех изменений, которые содержаться в коммитах. У каждого коммита есть свое имя, которое представляет собой результат хеш функции sha-1 от содержимого самого коммита.

Просмотреть коммиты можно при помощи команды

git log

Формат ответа этой команды по дефолту не очень удобен. Вот такая команда выведет ответ в более читаемом виде

git log --pretty=format:"%H [%cd]: %an - %s" --graph --date=format:%c

Что бы закончить просмотр нужно нажать на клавишу q
Посмотреть, что находиться в рабочей директории и staging area можно командой

git status

Рабочую директорию можно переключить на предыдущее состояние выполнив команду

git checkout <hash коммита>

Только перед тем как это делать выполните git status и убедитесь, что у вас нет никаких локальных и не зафиксированных изменений. Иначе Git не поймет, как ему переключаться. git status подскажет вам что можно сделать с локальными изменениями что бы можно было переключиться. Этого правила следует придерживаться и при всяких других переключениях рабочей области.

Ветка

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

Сделать новую ветку и переключиться на нее можно выполнив команды

git pull
git checkout –b <имя новой ветки>


Просто сделать ветку, не переключаясь на нее можно командой

git branch <имя ветки>

переключиться на ветку

git checkout <имя ветки>

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

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

Существует другая ситуация при объединении веток, в которой merge может произойти без merge commit. Дело в том, что если в одной из веток не произошло никаких изменений, то необходимость в merge commit с двумя предками отпадает. В таком случае, при слиянии веток, Git просто сделает пометку о том, что дальше будут идти коммиты той ветки с которой эта ветка была объединена. Такая схема merge называется слияние-перемотка (fast-forward merge), визуально это можно представить вот так.

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

git checkout <имя ветки>

Потом получить последние изменения сделанные в этой ветке выполнив

git pull

Затем выполнить команду

git merge <имя ветки>

Так выглядит работа с ветками в общих чертах.

Обратите внимание на то, что перед тем как заводить новую ветку нужно выполнить git pull. Делается это по нескольким причинам.

• Другой программист мог изменить код, в том числе внести такие изменения, которые повлияют на решение задачи, для которой вы заводите новую ветку. Эти изменения могут вам пригодиться при решении своей задачи.
• Из-за этих изменений вы можете получить конфликт при мерже.
• Больше шанс что у вас получится merge commit. Это не так плохо, как два предыдущих пункта. Но если можно избежать лишнего коммита, то почему бы этого не сделать?

Популярные схемы работы с ветками в Git

Теперь можно описать популярные схемы работы с ветками в гите.

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

Классическая схема работы с ветками

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

Именная ветка

Неопытные программисты заводят себе именную ветку и работают всегда в ней. Они решают по одной задачи за раз, и когда заканчивают решение одной из задач, делают новый Pull запрос через Web интерфейсе (об этом чуть ниже). Недостаток этого подхода в том, что так можно решать только одну задачу и нельзя быстро переключиться на решение другой задачи. Еще один недостаток в том, что ветки так со временем будут все сильнее расходиться и код в ветке программиста рано или поздно устареет относительно мастер ветки и его придется обновить. Для этого можно либо смержить мастер ветку в ветку программиста, либо завести новую ветку для этого программиста от последнего рабочего состояния в мастер ветке. Правда к тому времени, как это произойдет программист уже может освоить гит в достаточной мере что бы перейти на “классическую” схему работы. Таким образом эта схема имеет место быть для неопытных пользователей Git.

Схема с dev веткой

Другая схема очень похожа на классическую, только в ней помимо мастер ветки есть еще девелоперская ветка, которая деплоится на тестовый сервер. Такую ветку обычно называют dev. Схема работы при этом такая. Программист перед выполнением новой задачи заводит для нее ветку от последнего рабочего состояния в мастер ветке. Когда он заканчивает работу над задачей, то мержит ветку задачи в dev ветку самостоятельно. После этого, совместными усилиями задача тестируется на тестовом сервере вместе с остальными задачами. Если есть ошибки, то задачу дорабатывают в той же ветке и повторно мержат с dev веткой. Когда тестирование задачи заканчивается, то ВЕТКУ ЗАДАЧИ мержат с мастер веткой. Важно заметить, что в этой схеме работы с мастер веткой нужно мержить ветку задачи, а не dev ветку. Ведь в dev ветке будут содержаться изменения, сделанные не только в этой задаче, но и в других и не все эти изменения могут оказаться рабочими. Мастер ветка и dev ветка со временем будут расходиться, поэтому при такой схеме работы периодически заводят новую dev ветку от последнего рабочего состояния мастер ветки. Недостатком этого подхода является избыточность, по сравнению с классической схемой. Такую схему работы с ветками часто используют если в проекте нет автоматизированных тестов и все тестирование происходит вручную на сервере разработки.

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

Pull запросы

С этим понятием имеется путаница. Дело в том, что в Git есть две совершенно разные вещи, которые можно назвать Pull запросом. Одна из них, это консольная команда git pull. Другая это кнопка в web интерфейсе репозитория. На github.com она выглядит вот так

Про эту кнопку и пойдет речь дальше.

Если программист достаточно опытный и ответственный, то он обычно сам сливает свой код в мастер ветку. В противном случае программист делает так называемый Pull запрос. Pull запрос это по сути дела запрос на разрешение сделать merge. Pull запрос можно сделать из web интерфейса Git, или при помощи команды git request-pull. После того как Pull запрос создан, остальные участники могут увидеть это, просмотреть тот код который программист предлагает внести в проект, и либо одобрить этот код либо нет. Merge через pull запросы имеет свои плюсы и минусы. Минус в том, что для тесной команды опытных программистов такой подход будет лишним. Это будет только тормозить работу и вносить в нее оттенки бюрократии.

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

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

Конфликты

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

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

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

git tag -a v1.0

Что бы передать ветки в удаленный репозиторий нужно выполнить команду

git push –tags

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

git checkout <имя тега>

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

Если вы будете придерживаться этих правил и “классической” схемы работы с ветками, то вам будет проще интегрировать ваш Git с другими системами. Например, с системой непрерывной интеграции или с репозиторием пакетов, таким как packagist.org. Обычно сторонние решения и всякие расширения рассчитаны именно на такую схему работы с гитом, и если вы сразу начнете делать все правильно, то это может стать большим плюсом для вас в дальнейшем.

Это обзор основных моментов при работе с Git. Если вы хотите узнать про Git больше, то я вам посоветую прочитать книгу Pro Git. Вот здесь.

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