Знакомимся с Git за 30 минут

Основы

Git — это набор утилит командной строки, которые позволяют отслеживать и записывать изменения в файлах (чаще всего это относится к файлам с исходным кодом, но вы можете отслеживать все, что захотите). С его помощью вы можете восстанавливать старые версии вашего проекта, сравнивать, анализировать, объединять изменения и делать многое другое. Все эти действия можно назвать термином «контроль версий». Существует множество других систем контроля версий, похожих по своему функционалу на Git. Возможно, вы слышали о них раньше. Вот некоторые из них: SVN, Mercurial, Perforce, CVS, Bitkeeper.

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

1. Устанавливаем Git

Установить Git на свой компьютер довольно просто.

• Linux – просто откройте окно терминала и установите git, используя пакетный менеджер. Для пользователей Ubuntu команда будет следующей: sudo apt-get install git
• Windows — мы рекомендуем git для Windows, потому что в нем есть и GUI-клиент, и терминал командной строки.
• OS X – проще всего установить homebrew, а затем запустить команду brew install git в окне терминала.

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

2. Настраиваем Git

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

$ git config --global user.name "My Name"
$ git config --global user.email myEmail@example.com

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

3. Создаем новый репозиторий – git init

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

Создайте новую папку на вашем рабочем столе с именем git_exercise, откройте новое окно терминала и выполните следующие команды:

$ cd Desktop/git_exercise/
$ git init

В результате вы увидите строку, приблизительно следующего содержания: Initialized empty Git repository in /home/user/Desktop/git_exercise/.git/

Это означает, что наш репозиторий успешно создан, но пока пуст. Давайте создадим простой текстовый файл и сохраним его в папке git_exercise.

4. Проверяем статус -git status

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

$ git status
On branch master
Initial commit
Untracked files:
(use "git add ..." to include in what will be committed)

 hello.txt

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

5. Добавляем файл для индексирования -git add

У Git существует понятие “staging area” (область подготовленных файлов). Ее можно сравнить с чистым холстом, на который записываются изменения в файлах, которые вы можете зафиксировать в последствии. Изначально staging area – пуста, но вы можете добавить в нее файлы с помощью git add, а затем сделать «снимок» состояния (коммит) с помощью git commit.

В нашем случае у нас только один файл. Так давайте добавим его.

$ git add hello.txt

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

$ git add -A

Проверив статус сейчас, мы увидим другое сообщение, по сравнению с предыдущим

$ git status
On branch master
Initial commit
Changes to be committed:
(use "git rm --cached ..." to unstage)
new file: hello.txt

Наш файл готов к коммиту. Сообщение также информирует нас о том, какое событие произошло с файлами в staging area. В нашем случае добавлен новый файл. Кроме создания файла, также могут произойти следующие события: файл может быть удален или изменен. Отсчет идет с момента последнего вызова команды git add.

6. Коммит –git commit

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

$ git commit -m "Initial commit."

После этого будет создан новый коммит (снимок) со всеми изменениями из staging area (добавление файла hello.txt). В кавычках добавлено описание, в котором пользователь отражает какие изменения хранятся в текущем «снимке». Хорошей практикой при разработке считается следующая: нужно делать коммиты почаще и всегда добавлять к ним осмысленные комментарии.

Удаленные репозитории

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

Подключение к удаленному репозиторию – git remote add

Чтобы разместить что-либо в удаленном репозитории, сначала нужно соединиться с ним. Предположим, что адрес нашего репозитория - https://github.com/tutorialzine/awesome-project. Советуем вам создать собственный пустой репозиторий на GitHub, BitBucket или другом сервисе. Регистрация и настройка может занять некоторое время, но на указанных сервисах имеются пошаговые инструкции, которые вам помогут.

Чтобы связать ваш локальный репозиторий с удаленным, необходимо выполнить в терминале следующую команду:

# Замените значение URL в примере на адрес вашего репозитория
$ git remote add origin https://github.com/tutorialzine/awesome-project.git

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

Загрузка на сервер – git push

Настало время переместить наши локальные коммиты на сервер. Это можно сделать с помощью команды git push, которая принимает 2 параметра: название репозитория (в нашем случае origin) и имя ветки, в которую перемещаются данные (по-умолчанию, это master в любом репозитории). Эти действия делаются каждый раз, когда вы хотите обновить данные в удаленном репозитории.

$ git push origin master

Counting objects: 3, done.
Writing objects: 100% (3/3), 212 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/tutorialzine/awesome-project.git
* [new branch] master -> master

Для выполнения этой команды в большинстве сервисов вам необходимо будет пройти аутентификацию. Если команда выполнена успешно, при входе в свой аккаунт через браузер вы увидите, что файл hello.txt доступен в удаленном репозитории.

Клонирование репозитория – git clone

На Github любой посетитель может просматривать ваш удаленный репозиторий. Кроме того, существует возможность импортировать его к себе в локальный репозиторий и получить полную рабочую копию вашего проекта. Сделать это можно с помощью команды git clone.

$ git clone https://github.com/tutorialzine/awesome-project.git

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

Получение актуальной копии с сервера – git pull

Если вы что-то изменили в вашем проекте и загрузили изменения в удаленный репозиторий, пользователи смогут скачать актуальную копию с помощью простой команды git –pull.

$ git pull origin master

From https://github.com/tutorialzine/awesome-project
* branch master -> FETCH_HEAD
Already up-to-date.

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

Git ветки (branches)

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

Существует несколько «плюсов» использования веток:

• В процессе работы над проектом стабильная версия не будет испорчена;
• Несколько человек одновременно могут добавлять различный новый функционал в проект;
• Разработчики могут работать в своих ветках, не беспокоясь о том, что кто-то изменить их код;
• Несколько версий одного и того же функционала могут создаваться в разных ветках. По завершении разработки вы можете их сравнить и выбрать лучшую.

Создание новой ветки – git branch

По-умолчанию, в каждом репозитории всегда имеется ветка с названием master. Чтобы создать дополнительные ветки используйте команду git branch <name>

$ git branch amazing_new_feature/span>

Создается новая ветка, точная копия master на данный момент времени.

Переход на ветку – git checkout

С помощью команды git branch, мы можем просмотреть все доступные ветки репозитория.

$ git branch
amazing_new_feature
* master

Текущей веткой является master. Она помечена символом «*». Однако, если мы решим начать разрабатывать новый функционал, нам будет необходимо переключиться на другую ветвь. Это делается с помощью команды git checkout с указанием имени ветки в параметрах.

$ git checkout amazing_new_feature

Объединение веток – git merge

Предположим, что наш замечательный функционал будет храниться в файле feature.txt. Давайте создадим его и сделаем коммит.

$ git add feature.txt
$ git commit -m "New feature complete."

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

$ git checkout master

Если сейчас открыть папку проекта в файловом менеджере, мы обнаружим, что файл feature.txt отсутствует. Дело в том, что мы перешли на ветку, в которой этот файл никогда не создавался. Чтобы перенести его сюда, необходимо объединить 2 эти ветки (git merge). Таким образом, изменения сделанные в ветке amazing_new_feature, будут перенесены в основную ветку проекта.

git merge amazing_new_feature

Теперь обе ветки идентичны. Так как новый функционал добавлен в проект, ветка amazing_new_feature нам больше не нужна. Удалим ее.

git branch -d awesome_new_feature

«Продвинутые» возможности Git

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

Отслеживание изменений между коммитами

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

$ git log

commit ba25c0ff30e1b2f0259157b42b9f8f5d174d80d7
Author: Tutorialzine
Date: Mon May 30 17:15:28 2016 +0300

New feature complete

commit b10cc1238e355c02a044ef9f9860811ff605c9b4
Author: Tutorialzine
Date: Mon May 30 16:30:04 2016 +0300

Added content to hello.txt

commit 09bd8cc171d7084e78e4d118a2346b7487dca059
Author: Tutorialzine
Date: Sat May 28 17:52:14 2016 +0300

Initial commit

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

Чтобы увидеть, что происходило в последнем коммите, запустите команду git show [commit].

$ git show b10cc123

commit b10cc1238e355c02a044ef9f9860811ff605c9b4
Author: Tutorialzine
Date: Mon May 30 16:30:04 2016 +0300

Added content to hello.txt

diff --git a/hello.txt b/hello.txt
index e69de29..b546a21 100644
--- a/hello.txt
+++ b/hello.txt
@@ -0,0 +1 @@
+Nice weather today, isn't it?

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

$ git diff 09bd8cc..ba25c0ff

diff --git a/feature.txt b/feature.txt
new file mode 100644
index 0000000..e69de29
diff --git a/hello.txt b/hello.txt
index e69de29..b546a21 100644
--- a/hello.txt
+++ b/hello.txt
@@ -0,0 +1 @@
+Nice weather today, isn't it?

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

Откат файла к предыдущей версии.

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

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

$ git checkout 09bd8cc1 hello.txt

Откат коммита целиком

Если сразу после совершения коммита вы заметили, что вы сделали опечатку в комментарии к нему или забыли добавить файл, это с легкостью можно исправить с помощью команды git commit --amend. Эта команда вернет все файлы из коммита в область подготовленных файлов (staging area) и позволит сделать коммит снова. Таким образом вы можете исправить опечатки или добавить файлы в staging area.

Чтобы сделать откат до более давнего коммита нужно использовать команду git revert. Это отменит все изменения до момента, когда был сделан указанный вами коммит. Также эта команда применяется, если ваш последний коммит уже залит на сервер.

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

$ git revert HEAD

Для более давних ID указывается обязательно.

$ git revert b10cc123

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

Разрешение конфликтов слияния

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

Давайте рассмотрим пример, в котором мы пытаемся объединить 2 ветки, именуемые john_branch и tim_branch. Оба разработчика написали в одном и том же файле функцию, которая отображает элементы массива.

Джон для этого использовал цикл for:

// Используем цикл for и console.log
for(var i=0; i<arr.length; i++) {
    console.log(arr[i]);
}

Тим предпочел использовать forEach:

// Используем forEach и console.log
arr.forEach(function(item) {
    console.log(item);
});

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

$ git merge tim_branch

Auto-merging print_array.js
CONFLICT (content): Merge conflict in print_array.js
Automatic merge failed; fix conflicts and then commit the result.

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

<<<<<<< HEAD
// Используем цикл for и console.log
for(var i=0; i console.log(arr[i]);
}
=======
// Используем forEach и console.log
arr.forEach(function(item) {
console.log(item);
});
>>>>>>> Tim's commit.

Над символами «===» мы можем видеть код, который был в нашем коммите, а под ним конфликтный участок. В нашем примере мы четко видим различия, поэтому несложно решить чья версия кода лучше. Возможно, стоит переписать код полностью. В нашем примере мы так и сделаем, а затем удалим маркеры, это позволит Git понять, какие изменения мы сделали.

// Не используем цикл for и forEach.
// Используем Array.toString() для отображения данных из массива
console.log(arr.toString());

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

$ git add -A
$ git commit -m "Array printing conflict resolved."

Как вы можете видеть этот процесс довольно утомительный. Особенно это заметно, если проект довольно крупный. Поэтому большинство разработчиков предпочитают разрешать конфликты при помощи клиента с графическим интерфейсом, который значительно упрощает решение этой задачи. Чтобы запустить его воспользуйтесь командой git mergetool.

Создаем файл.gitignore

В большинстве проектов присутствуют файлы или целые папки, состояние которых не нужно контролировать. Чтобы быть уверенным, что они не попадут в коммит при использовании команды git add –A, нужно создать файл .gitignore.

Для этого:

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

Обычно в список входят следующие файлы:

• Файлы с логами;
• Папка node_modules в проектах на Node.js;
• Папки, создаваемые в проектах средами разработки, такими как Netbeans и IntelliJ;
• Персональные скрипты разработчика;

Файл .gitignore, запрещающий все файлы из выше приведенного списка, выглядит следующим образом:

*.log
build/
node_modules/
.idea/
my_notes.txt

Символ «/» в конце некоторых строк, говорит о том, что это папка и Git должен игнорировать все находящееся внутри нее, включая подпапки. Символ «*» в данном случае означает фильтр по определенному типу файлов.

Заключение

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

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

• Официальная документация по Git (в том числе видеоуроки)
• Уроки и статьи от Atlassian
• Список клиентов с графическим интерфейсом
• Шпаргалка по Git (PDF)
• Онлайн инструмент для создания файлов .gitignore

Оригинал статьи