Git инструкция шпаргалка для начинающих

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

История Git начинается в 2005 году, когда Линус Торвальдс, создатель ядра Linux, начал разработку новой системы контроля версий для управления исходным кодом ядра Linux. Он был недоволен тогдашними системами контроля версий, которые были неэффективными или сложными в использовании. Git был создан как быстрый, эффективный и легко расширяемый инструмент для работы с крупными проектами с распределенной архитектурой.

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

Команда git clone используется для создания локальной копии удаленного репозитория Git. Это позволяет вам получить копию проекта на вашем локальном компьютере и начать работу с ним.

Синтаксис команды git clone:

git clone <URL репозитория> [<название локальной папки>]

где <URL репозитория> — это URL-адрес удаленного репозитория Git, а <название локальной папки> (необязательный параметр) — это название локальной папки, в которую будет склонирован репозиторий. Если <название локальной папки> не указан, Git автоматически создаст папку с названием репозитория.

Пример использования команды git clone:

git clone https://github.com/username/repo.git

Эта команда создаст локальную копию удаленного репозитория repo, который находится в аккаунте username на GitHub, в папке с названием repo.

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

git clone https://github.com/username/repo.git myproject

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

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

Синтаксис команды git init:

git init [--bare] [<directory>]

—bare — определяет репозиторий как «голый», т.е. без рабочей директории. Это используется для создания удаленного репозитория.

<directory> — указывает директорию, в которой создается локальный репозиторий. Если параметр не указан, репозиторий создается в текущей директории.

Пример использования команды git init:

$ cd my_project
$ git init
Initialized empty Git repository in /path/to/my_project/.git/

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

Флаг —bare используется для создания «голого» удаленного репозитория. Например:

$ mkdir my_repo.git
$ cd my_repo.git
$ git init --bare
Initialized empty Git repository in /path/to/my_repo.git/

Эта команда создает новый удаленный репозиторий Git в директории my_repo.git. Флаг —bare указывает, что это «голый» репозиторий, т.е. без рабочей директории.

Команда git init также поддерживает другие опции и флаги, которые можно использовать в различных сценариях. Например, флаг —template позволяет указать кастомный шаблон инициализации, а опция —separate-git-dir позволяет разместить репозиторий в другой директории. Список всех опций и флагов можно посмотреть в документации Git.

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

Синтаксис команды git add . :

git add .

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

Пример использования команды git add . :

Создайте новый файл с названием file.txt в вашей рабочей директории и добавьте в него какой-то текст.

Выполните команду git status, чтобы увидеть изменения в рабочей директории:

$ git status
On branch master
Untracked files:
(use "git add <file>..." to include in what will be committed)
file.txt

nothing added to commit but untracked files present (use "git add" to track)

Вы видите, что файл file.txt еще не отслеживается Git.

Выполните команду git add ., чтобы добавить все измененные файлы в рабочей директории в индекс:

$ git add .

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

$ git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: file.txt

Вы видите, что файл file.txt был добавлен в индекс.

Выполните команду git commit, чтобы сохранить изменения в репозитории Git:

$ git commit -m "Added file.txt"
[master 0e3b0a7] Added file.txt
1 file changed, 1 insertion(+)
create mode 100644 file.txt

Вы видите, что файл file.txt был успешно добавлен в репозиторий Git.

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

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

Синтаксис команды git commit:

git commit -m "<сообщение коммита>"

Где -m означает «message» (сообщение) и <сообщение коммита> — это краткое описание изменений, сделанных в коммите.

Пример использования команды git commit:

Добавьте изменения в индекс с помощью команды git add (например, git add filename.txt или git add . для добавления всех измененных файлов в индекс). Сделайте коммит с помощью команды git commit и передайте сообщение коммита в кавычках, чтобы описать, что было изменено. Например:

git commit -m "Добавлен новый файл README.md"

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

Кроме того, команду git commit можно дополнительно настраивать, используя различные параметры, например, -a (автоматически добавляет все измененные файлы в индекс) или —amend (используется для изменения последнего коммита). Для получения подробной информации о доступных параметрах команды git commit можно обратиться к документации Git.

Команда git push используется для отправки изменений из вашего локального репозитория в удаленный репозиторий Git. Это позволяет обновить содержимое удаленного репозитория на основе ваших локальных изменений.

Синтаксис команды git push:

git push <remote> <branch>

Где <remote> — это имя удаленного репозитория, куда вы хотите отправить изменения, а <branch> — это название ветки, которую вы хотите отправить.

Пример использования команды git push:

git push origin main

Эта команда отправляет изменения из вашей локальной ветки main в удаленный репозиторий с именем origin.

Помимо базового синтаксиса, команда git push имеет несколько флагов, которые можно использовать для дополнительной настройки:

-u или —set-upstream — устанавливает отслеживание для ветки, что позволяет вам использовать git push и git pull без указания имени удаленного репозитория и названия ветки;
-f или —force — заставляет Git принудительно заменить удаленную ветку измененной локальной веткой, даже если это приведет к потере данных;
-n или —dry-run — позволяет вам протестировать команду git push, не отправляя реальных изменений в удаленный репозиторий;
-v или —verbose — выводит дополнительную информацию о процессе отправки изменений.

Пример использования команды git push с флагом:

git push -u origin main

Эта команда отправляет изменения из вашей локальной ветки main в удаленный репозиторий с именем origin и устанавливает отслеживание для этой ветки.

git status 

Команда git status используется для получения информации о текущем состоянии вашего рабочего пространства Git. Она показывает, какие файлы были изменены, какие из них были добавлены в индекс, и какие из них готовы к коммиту. Кроме того, команда «git status» сообщает о текущей ветке и другой полезной информации.

Синтаксис команды «git status»:

git status [-s] [--long] [--branch] [--porcelain] [--ignore-submodules[=<when>]]

Основные флаги:

«-s» или «—short«: показывает краткую информацию о состоянии файлов в формате «git diff —shortstat».
«—long«: показывает длинный формат состояния файлов, включая информацию о последнем коммите для каждого файла.
«—branch«: показывает текущую ветку и ее состояние.
«—porcelain«: показывает состояние файлов в машинно-читаемом формате, что полезно для автоматизации.
«—ignore-submodules«: позволяет игнорировать изменения в подмодулях.

Пример использования команды «git status»:

$ git status

На ветке main
Ваша ветка опережает «origin/main» на 1 коммит.
  (используйте «git push», чтобы опубликовать локальные коммиты)

изменения, которые будут включены в коммит:
  (используйте «git restore --staged <file>...», чтобы убрать из индекса)

        изменён:   README.md

изменения, которые не проиндексированы для коммита:
  (используйте «git add <file>...», чтобы проиндексировать)

        изменён:   index.html

нет изменений добавленных для коммита (используйте «git add» и/или «git commit -a»)

Эта команда показывает, что находитесь на ветке «main», ваша локальная ветка опережает ветку «origin/main» на один коммит, и что были внесены изменения в файлы «README.md» и «index.html». Файл «README.md» был проиндексирован и готов к коммиту, а файл «index.html» не был проиндексирован. Для того, чтобы проиндексировать файл «index.html», нужно использовать команду «git add index.html».

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

Основной синтаксис команды git diff выглядит так:

git diff [<опции>] [<источник>] [<цель>]

Где:

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

Основные флаги git diff:

—cached — сравнивает изменения между вашим индексом (т.е. тем, что будет в следующем коммите) и последним коммитом.
—stat — показывает статистику изменений для каждого файла.
—color — отображает различия с использованием цветов для лучшей читаемости.

Примеры использования:

git diff - простой запуск команды покажет различия между вашей рабочей копией и последним коммитом.
git diff --cached - покажет различия между вашим индексом и последним коммитом.
git diff HEAD - покажет различия между вашей рабочей копией и последним коммитом.
git diff HEAD~2 HEAD - покажет различия между двумя последними коммитами.
git diff --stat - покажет статистику изменений для каждого файла.
git diff --color - покажет различия с использованием цветов.

Кроме того, можно использовать git diff для сравнения любых двух коммитов, веток или тэгов в репозитории. Например, git diff branch1..branch2 покажет различия между двумя ветками branch1 и branch2.

Команда git log используется для просмотра истории коммитов в репозитории Git. Она отображает список коммитов в обратном хронологическом порядке, начиная с последнего.

Пример использования команды git log:

git log

Эта команда показывает список всех коммитов в репозитории, от самых последних до самых старых. Каждый коммит включает SHA-1 хеш, автора коммита, дату и время коммита, и комментарий.

Основные флаги команды git log:

—oneline: показывает каждый коммит в одной строке, содержащей только его SHA-1 хеш и комментарий.

—graph: показывает историю коммитов в виде графа, что позволяет легко визуализировать разветвленную историю ветвлений и слияний.

—author=<имя>: показывает только коммиты, сделанные указанным автором.

—since=<дата>: показывает только коммиты, сделанные после указанной даты.

—until=<дата>: показывает только коммиты, сделанные до указанной даты.

-n <количество>: показывает только указанное количество последних коммитов.

—grep=<строка>: показывает только коммиты, содержащие указанную строку в своих комментариях.

Пример использования флага —since:

git log --since=2022-01-01

Эта команда показывает список всех коммитов, сделанных после 1 января 2022 года.

Пример использования флага —author:

git log --author="John Doe"

Эта команда показывает список всех коммитов, сделанных автором с именем «John Doe».

Пример использования флага —grep:

git log --grep="bug"

Эта команда показывает список всех коммитов, содержащих слово «bug» в своих комментариях.

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

Основные флаги:

-b: создать новую ветку и переключиться на нее. Например, git checkout -b new-branch создаст новую ветку с названием «new-branch» и переключится на нее.
-f: принудительно перезаписывает локальные изменения, которые не были зафиксированы. Этот флаг используется только в крайних случаях.
-p: позволяет просмотреть и выбрать конкретные изменения для восстановления.
<commit/branch>: позволяет переключиться на определенный коммит или ветку.

Примеры использования:

Переключение на ветку:

git checkout main

Эта команда переключает вас на ветку «main».

Создание новой ветки и переключение на нее:

git checkout -b new-branch

Эта команда создает новую ветку с названием «new-branch» и переключает вас на нее.

Переключение на определенный коммит:

git checkout 2a3e8c9

Эта команда переключает вас на коммит с указанным идентификатором.

Отмена изменений в файле:

git checkout myfile.txt

Эта команда отменяет изменения в файле «myfile.txt» и восстанавливает его до последней зафиксированной версии.

Восстановление определенных изменений:

git checkout -p myfile.txt

Эта команда позволяет вам просмотреть изменения в файле «myfile.txt» и выбрать, какие из них восстановить.

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

Основные флаги команды git branch:

-a — показывает все ветки (включая удаленные)
-d — удаляет ветку (данная команда удаляет только те ветки, которые были слиты в текущую ветку)
-D — удаляет ветку без проверки, были ли все её изменения слиты с текущей веткой
-m — переименовывает текущую ветку
-r — показывает все удаленные ветки

Примеры использования команды git branch:

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

git branch

Создание новой ветки:

git branch new-branch

Переименование текущей ветки:

git branch -m new-branch-name

Удаление ветки:

git branch -d branch-to-delete

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

git branch -r

Команда git branch позволяет управлять ветками в репозитории и помогает организовать работу в команде. Она также помогает контролировать историю изменений в проекте.

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

Синтаксис команды git fetch:

git fetch [<remote>] [<refspec>...]

Основные флаги:

<remote>: имя удаленного репозитория Git (например, origin). Если не указан, Git использует имя origin по умолчанию.
<refspec>: имена веток и тегов, которые вы хотите получить из удаленного репозитория. Если не указан, Git получает все ветки и теги.

Пример использования команды git fetch:

git fetch

Эта команда получает все изменения из удаленного репозитория Git, который связан с вашим локальным репозиторием. После выполнения этой команды вы можете выполнить команду git log origin/master для просмотра истории изменений в удаленной ветке master.

git fetch origin feature-branch

Эта команда получает все изменения из удаленной ветки feature-branch в удаленном репозитории Git, связанном с вашим локальным репозиторием. После выполнения этой команды вы можете выполнить команду git log origin/feature-branch для просмотра истории изменений в удаленной ветке feature-branch.

Команда git pull используется для получения изменений из удаленного репозитория и объединения их с вашей локальной веткой.

Основной синтаксис команды git pull выглядит следующим образом:

git pull [<options>] [<repository> [<refspec>...]]

Основные флаги git pull:

—rebase: выполняет перебазирование текущей ветки на самый новый коммит вместо создания слияния (merge). Рекомендуется использовать этот флаг, если вы хотите, чтобы история коммитов оставалась простой и понятной.
—no-rebase: отменяет перебазирование и выполняет слияние вместо этого.
—no-commit: предотвращает создание автоматического коммита после выполнения слияния. Это дает возможность внести дополнительные изменения перед фиксацией изменений.
—ff-only: выполнить слияние только в том случае, если это можно сделать быстрым перемещением ветки вперед (fast-forward).
—no-ff: выполнить слияние только как коммит слияния (merge commit), даже если это можно сделать быстрым перемещением ветки вперед.

Примеры использования команды git pull:

Простой git pull, который получает изменения из удаленной ветки и автоматически объединяет их с локальной веткой:

git pull

git pull с использованием флага —rebase, который перебазирует текущую ветку на самый новый коммит из удаленной ветки вместо создания слияния:

git pull --rebase

git pull с использованием флага —no-commit, который предотвращает создание автоматического коммита после выполнения слияния:

git pull --no-commit

git pull с использованием флага —ff-only, который выполнит слияние только в том случае, если это можно сделать быстрым перемещением ветки вперед (fast-forward):

git pull --ff-only

git pull с использованием флага —no-ff, который выполнит слияние только как коммит слияния (merge commit), даже если это можно сделать быстрым перемещением ветки вперед:

git pull --no-ff

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

Синтаксис команды git merge:

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

где <имя ветки> — это имя ветки, изменения из которой вы хотите объединить в текущую ветку.

Пример использования команды git merge:

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

git checkout master

Затем вы можете выполнить команду git merge, указав имя ветки, из которой вы хотите получить изменения:

git merge feature-branch

В этом примере мы объединяем изменения из ветки feature-branch в текущую ветку master.

Основные флаги команды git merge:

—no-ff: Отключает быстрое слияние, что создает коммит с объединением, даже если изменения можно было бы просто быстро применить.
—abort: Отменяет текущее слияние и возвращает репозиторий в предыдущее состояние.

Пример использования флага —no-ff:

git merge --no-ff feature-branch

В этом примере мы отключаем быстрое слияние и создаем новый коммит с объединением.

Пример использования флага —abort:

git merge --abort

В этом примере мы отменяем текущее слияние и возвращаем репозиторий в предыдущее состояние.

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

Основные флаги:

-i (или —interactive): запускает интерактивный режим, который позволяет изменять порядок, объединять или отбрасывать коммиты.
-m (или —merge): используется, когда нужно перебазировать ветку слияния.
—onto <branch>: перебазирует текущую ветку на указанную ветку.

Примеры использования команды git rebase:

Перебазирование текущей ветки на другую ветку:

git checkout feature-branch
git rebase main

В этом примере текущая ветка feature-branch перебазируется на ветку main. Это означает, что изменения из ветки main будут применены поверх коммитов в ветке feature-branch.

Перебазирование текущей ветки на определенный коммит:

git checkout feature-branch
git rebase abc123

В этом примере текущая ветка feature-branch перебазируется на коммит с хеш-кодом abc123. Это означает, что изменения из этого коммита и всех коммитов после него будут применены поверх коммитов в ветке feature-branch.

Использование интерактивного режима:

git checkout feature-branch
git rebase -i main

В этом примере запускается интерактивный режим, который позволяет изменять порядок, объединять или отбрасывать коммиты при перебазировании ветки feature-branch на ветку main.

Перебазирование ветки слияния:

git checkout merge-branch
git rebase -m main

В этом примере ветка merge-branch, являющаяся веткой слияния, перебазируется на ветку main. Опция -m используется для корректной обработки коммитов слияния.

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

Синтаксис команды git revert:

git revert <commit>

где <commit> — это хэш-идентификатор коммита, который нужно отменить.

Пример использования команды git revert:

$ git log --oneline
d3b3d43 Commit C
786f7f8 Commit B
12556fa Commit A

$ git revert d3b3d43

Эта команда создаст новый коммит, который отменяет изменения, внесенные коммитом с хэш-идентификатором d3b3d43.

Флаги:

—no-commit: применить изменения, но не создавать новый коммит. Это позволяет вам проверить изменения перед тем, как закоммитить их.
-m parent-number: используется, если коммит имеет несколько родительских коммитов (как в случае с объединением веток). Он указывает, какой из родительских коммитов следует использовать при выполнении операции отмены.

Пример использования команды git revert с флагом —no-commit:

$ git revert --no-commit d3b3d43
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
        modified:   file.txt

Эта команда отменяет изменения, внесенные коммитом с хэш-идентификатором d3b3d43, и добавляет их в индекс. Но новый коммит не создается, пока не будет выполнена команда git commit.

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

. Пошаговое руководство: как выполнить слияние веток в git, как создать новую ветку и репозиторий, как выписать ветку с github и т.п. Инструкции по git для начинающих.

Git – это распределенная система контроля версий. Это главное отличие git от svn. Каждый разработчик создает на своем компьютере отдельный, полноценный репозиторий.

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

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

Вот пересмотренная шпаргалка по git с улучшенными названиями разделов и реорганизацией:

Установка и конфигурирование

# Инициализация нового репозитория Git
git init
# Клонирование и создание локальной копии удалённого репозитория
git clone <url>
# Настройте глобальные параметры Git
git config --global <имя_параметра> <значение>
# Настройка локальных параметров Git для конкретного репозитория
git config --local <имя_параметра> <значение>

# --------------- Расширенные ------------------

# Показать сводку настроек конфигурации Git
git config --list
# Установить пользовательский текстовый редактор для сообщений Git
git config --global core.editor " <команда_редактора>"
# Создать псевдоним команды Git
git config --global alias.<псевдоним> <команда>
# Включить автоматическое окрашивание вывода Git'а
git config --global color.ui auto
# Кэшировать учётные данные Git на определённое время
git config --global credential.helper 'cache --timeout=<секунды>'
# Настроить git на обнаружение определённых типов ошибок пробельных символов
git config --global core.whitespace <опции>
# Автоматически обрезать ветви удалённого отслеживания при получении обновлений
git config --global fetch.prune true
# Установить пользовательский инструмент diff для Git
git config --global diff.tool <инструмент>
# Установить пользовательский инструмент слияния для Git
git config --global merge.tool <инструмент>
# Сравнение изменения с помощью пользовательского инструмента diff
git difftool
# Разрешение конфликтов слияния с помощью пользовательского инструмента слияния
git mergetool

Файловые операции

# Показать состояние рабочего дерева
git status
# Добавить файлы в область хранения
git add <файл(ы)>
# Удалить файлы из рабочего дерева и области хранения
git rm <файл(ы)>
# Переместить или переименовать файл
git mv <старый_файл> <новый_файл>
# Коммит изменений с сообщением
git commit -m "сообщение коммита"
# Показать различия между рабочим деревом и последним коммитом
git diff

# --------------- Расширенные ------------------

# Предположить, что отслеживаемый файл не изменился
git update-index --assume-unchanged <файл>
# Восстановить нормальное поведение отслеживания изменений
git update-index --no-assume-unchanged <файл>
# Показать различия между двумя коммитами
git diff <коммит_id1>..<коммит_id2>
# Удалить файл, но сохранить в рабочем каталоге
git rm --cached <имя_файла>

Ветвление и слияние

# Список всех ветвей
git branch
# Создать новую ветвь
git branch <имя_ветви>
# Переход к определённой ветви
git checkout <имя_ветви>
# Объединить ветвь с текущей ветвью
git merge <имя_ветви>
# Удалить определённую ветвь
git branch -d <имя_ветви>
# Вывести список всех удалённых ветвей
git branch -r

# --------------- Расширенные ------------------

# Список ветвей с дополнительной информацией
git branch -vv
# Создать новую ветвь на основе удалённой ветви
git checkout -b <имя_ветви> <имя_удалённой_ветви>/<имя_удалённой_ветви>
# Отменить слияние в случае конфликтов
git merge --abort
# Перебазировать текущую ветвь на другую ветвь
git rebase <имя_ветви>
# Отменить текущую операцию ребазирования
git rebase --abort
# Интерактивное ребазирование для редактирования, сквоша, переупорядочивания или сброса коммитов
git rebase -i
# Интерактивный возврат коммитов в текущей ветви на удалённую ветвь
git rebase -i <имя_удалённой_ветви>/<удалённая_ветвь>

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

# Список удалённых репозиториев
git remote
# Добавить удалённый репозиторий
git remote add <имя> <url>
# Извлечение из удалённого репозитория
git fetch <имя_удалённого_репозитория>
# Извлечь изменения из удалённой ветви
git pull <имя_удалённого_репозитория> <удалённая_ветвь>
# Внести изменения в удалённый репозиторий
git push <имя_удалённого_репозитория> <локальная_ветвь>
# Удалить удалённый репозиторий
git remote rm <имя_удалённого_репозитория>
# Отображение информации о конкретном удалённом репозитории
git remote show <имя_удалённого_репозитория>
# Показать ветви отслеживания для удалённых репозиториев
git remote show <имя удалённого репозитория> --verbose

# --------------- Расширенные -------------------

# Получить обновления из всех удалённых репозиториев
git remote update
# Принудительная отправка изменений в удалённый репозиторий с перезаписью истории удалённого репозитория
git push --force <имя_удалённого_репозитория> <локальная_ветвь>
# Передача всех тегов в удалённый репозиторий
git push --tags <имя_удалённого_репозитория>
# Переименовать удалённый репозиторий
git remote rename <старое_имя> <новое_имя>
# Изменить URL удалённого репозитория
git remote set-url <имя> <новый_url>
# Удалить устаревшие ветви удалённого отслеживания
git remote prune <имя_удалённого_репозитория>
# Перечислить все удалённые ветви, которые были объединены в текущую ветвь
git branch -r --merged
# Список всех удалённых ветвей, которые ещё не объединены в текущую ветвь
git branch -r --no-merged
# Получение обновлений из удалённого репозитория и удаление устаревших ветвей удалённого отслеживания
git fetch -p

# Отслеживание удалённой ветви и настройка локальной ветви на автоматическую синхронизацию с ней
git branch --track <имя_ветви> <имя_удалённого_репозитория>/<имя_удалённой_ветви>
# Установить существующую локальную ветвь для отслеживания удалённой ветви
git branch -u <имя_удалённого_репозитория>/<имя_удалённой_ветви>
# Переместить ветвь в удалённый репозиторий и установить её для отслеживания удалённой ветви
git push -u <имя_удалённого_репозитория> <локальная_ветвь>
# Удалить ассоциацию отслеживания между локальной и удалённой веткой
git branch --unset-upstream <имя_ветви>

История коммитов

# Показать историю коммитов
git log
# Показать сжатую историю коммитов
git log --oneline
# Показать историю коммитов с ветвлением
git log --graph
# Фильтровать историю коммитов по автору
git log --author=<имя_автора>
# Показать историю коммитов с определённой даты
git log --since=<дата>
# Показать историю коммитов до определённой даты
git log --until=<дата>

Тэги

# Список всех тегов
git tag
# Создать новый тег для определённого коммита
git tag <имя_тега> <коммит_id>
# Создать аннотированный тег с сообщением
git tag -a <имя_тега> -m "сообщение тега"
# Удалить определённый тег
git tag -d <имя_тега>
# Удалить определённый удалённый тег
git push <имя_удалённого_репозитория> --delete <имя_тега>
# Показать информацию о конкретном теге
git show <имя_тега>

Тайники/Stashes

# Временно сохраните изменения в рабочем дереве
git stash save "сообщение тайника"
# Перечислить все тайники
git stash list
# Применить изменения из определённого тайника
git stash apply <тайник>
# Удалить определённый тайник
git stash drop <тайник>
# Удалить все тайники
git stash clear

Cherry-Picking

# Применить определённый коммит из одной ветки к другой
git cherry-pick <коммит_id>

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

# Изменить последний коммит
git commit --amend
# Создать новый коммит, который отменяет изменения предыдущего коммита
git revert <коммит_id>
# Отбросить изменения и переместить HEAD в определённый коммит
git reset --hard <коммит_id>
# Переместите HEAD на определённый коммит, но сохраните поэтапные изменения
git reset --soft <коммит_id>
# Показать запись всех изменений, внесённых в локальную голову репозитория
git reflog

Подмодули, поддеревья и расширенные подмодули

# Добавить подмодуль в текущий репозиторий
git submodule add <репозиторий_url> <путь>
# Инициализировать и обновить все подмодули рекурсивно
git submodule update --init --recursive
# Добавить поддерево в текущий репозиторий
git subtree add --prefix=<путь> <репозиторий_url>
# Инициализировать подмодули в репозитории
git submodule init
# Обновить подмодули до последних коммитов
git submodule update
# Выполнить определённую команду в каждом подмодуле
git submodule foreach <команда>
# Снять с регистрации подмодуль
git submodule deinit <путь>

Хуки и автоматизация, а также инструменты Diff и Merge

# Найти каталог hooks в репозитории Git (обычно в .git/hooks/)
git hooks
# Имена сценариев для конкретных хуков, которые могут быть добавлены в каталог hooks
pre-commit, post-commit, pre-push, post-merge и т.д.
# Делаем скрипт хука исполняемым, чтобы обеспечить его срабатывание в случае необходимости
chmod +x <скрипт_хука>

Работа с патчами

# Создать файл патча для определённого коммита
git format-patch <коммит_id>
# Применить патч к текущей ветке
git apply <файл_патча>
# Применить патч с помощью команды "git am" (применить почтовый ящик)
git am <файл_патча>

Совместная работа

# Сгенерировать сводку request-pull с изменениями между двумя коммитами
git request-pull <начальный_коммит> <конечный_коммит> <url>
# Обобщить историю коммитов, перечислив авторов и их вклад
git shortlog
# Список всех файлов, отслеживаемых Git'ом
git ls-files
# Поиск заданного шаблона в файлах, отслеживаемых Git'ом
git grep <шаблон>

Бисекция, отладка и проблемы производительности

# Начать сеанс бисекции, чтобы найти коммит, который ввёл ошибку
git bisect start
# Пометить коммит как "плохой", указывающий на то, что он содержит ошибку
git bisect bad <коммит_id>
# Пометить коммит как "хороший", указывающий на то, что он не содержит ошибку
git bisect good <коммит_id>
# Завершить сеанс биссекции и вернуться к исходной ветке/коммиту
git bisect reset
# Проверить целостность репозитория Git
git fsck
# Запустить сборку мусора для оптимизации производительности репозитория
git gc
# Удаление неотслеживаемых файлов и каталогов (используйте с осторожностью)
git clean -df

Советы и хитрости

# Интерактивный выбор частей (кусков) файлов для добавления
git add -p

# Показать историю коммитов и связанные с ними патчи для определённого файла
git log -p <имя_файла>
# Настройка формата вывода журнала git log
git log --pretty=format:"%h - %an, %ar : %s"
# Найти текст в сообщениях о коммитах (полезно для поиска конкретных изменений)
git log --grep="<текст>"
# Быстрый просмотр изменений в рабочем каталоге с момента последнего коммита
git diff --stat
# Отображение истории ветвей с оформлением, чтобы увидеть, где ветви разделились или объединились
git log --oneline --decorate --graph

# Сохранение изменений в рабочем дереве, включая неотслеживаемые файлы
git stash save -u
# Создание пустого коммита, полезно при тестировании правил защиты ветвей
git commit --allow-empty -m " Сообщение о пустом коммите"

# Настроить пейджер вывода git на выход, если вывод меньше одного экрана, и не очищать экран после отображения
git config --global core.pager 'less -RFX'
# Использовать функцию автокоррекции Git'а для исправления неправильно введённых команд
git config --global help.autocorrect 1
# Список псевдонимов для команд Git'а
git config --get-regexp alias

# Выполнить пробный запуск слияния без реального слияния ветвей
git merge --no-commit --no-ff <имя_ветви>
# Показать древовидное представление структуры репозитория
git ls-tree --name-only -r -t HEAD

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

Примечание Вы читаете улучшенную версию некогда выпущенной нами статьи.

1. Основы Git
2. Коммиты
3. Файловая система
4. Просмотр изменений
5. Удалённые репозитории
6. Работа с ветками
7. Продвинутое использование

Основы Git

Git — это система контроля версий (VCS), которая позволяет отслеживать и фиксировать изменения в коде: вы можете восстановить код в случае сбоя или откатить до более ранних версий. А ещё это must-have инструмент для взаимодействия нескольких разработчиков на одном проекте. Подробнее об этом в руководстве по командной разработке с Git.

С Git работают через командную строку или инструменты вроде GitHub Desktop. Команды Git принимают вид git <команда> <аргументы>, где аргументом может быть путь к файлу. В команды также включаются опции, которые обозначаются как --<опция>. Забыли, как использовать команду? Откройте руководство с git help <команда>.

Установка Git

Введение в Git всегда начинается с установки: скачайте Git для Windows, macOS или Linux и проверьте версию с помощью git --version.

Настройка конфигурационного файла

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

Вы можете напрямую отредактировать файл .gitconfig в текстовом редакторе или сделать это командой git config --global --edit. Для отдельных полей это git config --global <поле> <значение> — поля user.name и user.email.

Также можно настроить текстовый редактор для написания сообщений коммитов, используя поле core.editor. А вот поле commit.template позволяет указать шаблон, который будет использоваться при каждом коммите. Ещё одно полезное поле — alias, которое привязывает команду к псевдониму. Например, git config --global alias.st "status -s" позволяет использовать git st вместо git status -s

Команда git config --list выведет все поля и их значения из конфигурационного файла.

Создаём Git-репозиторий

Для инициализации нового репозитория .git подойдёт git init или, если хотите скопировать существующий, git clone <адрес репозитория>.

Коммиты

Основы работы с Git предполагают понимание коммитов. Команда git commit откроет текстовый редактор для ввода сообщения коммита. Также эта команда принимает несколько аргументов:

• -m позволяет написать сообщение вместе с командой, не открывая редактор. Например git commit -m "Пофиксил баг";
• -a переносит все отслеживаемые файлы в область подготовленных файлов и включает их в коммит (позволяет пропустить git add перед коммитом);
• --amend заменяет последний коммит новым изменённым коммитом, что бывает полезно, если вы неправильно набрали сообщение последнего коммита или забыли включить в него какие-то файлы.

Советы для эффективного введения в Git:

• Коммитьте как можно чаще.
• Одно изменение — один коммит: не помещайте все не связанные между собой изменения в один коммит, разделите их, чтобы было проще откатиться.
• Формат сообщений: заголовок должен быть в повелительном наклонении, меньше 50 символов в длину и должен логически дополнять фразу this commit will ___(this commit will fix bugs — этот коммит исправит баги). Сообщение должно пояснять, почему был сделан коммит, а сам коммит показывает, что изменилось.
• Если у вас много незначительных изменений, хорошим тоном считается делать небольшие коммиты при разработке, а при добавлении в большой репозиторий объединять их в один коммит.

История коммитов в Git

Коммиты хранят состояние файловой системы в определённый момент времени и указатели на предыдущие коммиты. Каждый коммит содержит уникальную контрольную сумму — идентификатор, который Git использует, чтобы ссылаться на коммит. Чтобы отслеживать историю, Git хранит указатель HEAD, который указывает на первый коммит (мы следуем по цепочке коммитов в обратном порядке, чтобы попасть к предыдущим коммитам).

Мы можем ссылаться на коммит либо через его контрольную сумму, либо через его позицию относительно HEAD, например HEAD~4 ссылается на коммит, который находится 4 коммитами ранее HEAD.

Файловая система Git

Git отслеживает файлы в трёх основных разделах:

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

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

Просмотр изменений в файловых системах

Команда git status отображает все файлы, которые различаются между тремя разделами. У файлов есть 4 состояния:

1. Неотслеживаемый (untracked) — находится в рабочей директории, но нет ни одной версии в HEAD или в области подготовленных файлов (Git не знает о файле).
2. Изменён (modified) — в рабочей директории есть более новая версия по сравнению с хранящейся в HEAD или в области подготовленных файлов (изменения не находятся в следующем коммите).
3. Подготовлен (staged) — в рабочей директории и области подготовленных файлов есть более новая версия по сравнению с хранящейся в HEAD (готов к коммиту).
4. Без изменений — одна версия файла во всех разделах, т. е. в последнем коммите содержится актуальная версия.

Примечание Файл может быть одновременно в состоянии «изменён» и «подготовлен», если версия в рабочей директории новее, чем в области подготовленных файлов, которая в свою очередь новее версии в HEAD.

Мы можем использовать опцию -s для команды git status, чтобы получить более компактный вывод (по строке на файл). Если файл не отслеживается, то будет выведено ??; если он был изменён, то его имя будет красным, а если подготовлен — зелёным.

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

• git diff — сравнение рабочей директории с областью подготовленных файлов;
• git diff --staged — сравнение области подготовленных файлов с HEAD.

Если использовать аргумент <файл/папка>, то diff покажет изменения только для указанных файлов/папок, например git diff src/.

Обновление файловых систем

Команда git add <файл/папка> обновляет область подготовленных файлов версиями файлов/папок из рабочей директории.

Команда git commit обновляет HEAD новым коммитом, который делает снимки файлов в области подготовленных файлов.

Действие команды git reset <коммит> состоит из трёх потенциальных шагов:

1. Переместить указатель HEAD на <коммит> (например, при откате коммита в рабочей директории и области подготовленных файлов будут более новые версии файлов, чем в HEAD). Также указатель HEAD ветки будет перемещён на этот коммит.
2. Обновить область подготовленных файлов содержимым коммита. В таком случае только в рабочей директории будут новейшие версии файлов.
3. Обновить рабочую директорию содержимым области подготовленных файлов. С этим нужно быть осторожнее, поскольку в итоге будут уничтожены изменения файлов.

По умолчанию команда git reset выполняет только шаги 1 и 2, однако её поведение можно изменить с помощью опций --soft (только 1 шаг) и --hard (все шаги).

Если передать путь к файлу/папке, то команда будет выполнена только для них, например git reset --soft HEAD~1 src/.

Команда git checkout HEAD <файл> приводит к тому же результату, что и git reset --hard HEAD <файл> — перезаписывает версию файла в области подготовленных файлов и в рабочей директорией версией из HEAD, то есть отменяет изменения после последнего коммита.

С другой стороны, git checkout <файл> (уже без HEAD) перезаписывает версию файла в рабочей директории версией в области подготовленных файлов, то есть отменяет изменения с момента последней подготовленной версии.

Наконец, git rm <файл> отменяет отслеживание файла и удаляет его из рабочей директории, опция --cached позволит сохранить файл.

Игнорирование файлов

Зачастую нам не нужно, чтобы Git отслеживал все файлы в репозитории, потому что в их число могут входить:

• файлы с чувствительной информацией вроде паролей;
• большие бинарные файлы;
• файлы сборок, которые генерируются после каждой компиляции;
• файлы, специфичные для ОС/IDE, например, .DS_Store для macOS или .iml для IntelliJ IDEA — нам нужно, чтобы репозиторий как можно меньше зависел от системы.

Для игнорирования используется файл .gitignore. Чтобы отметить файлы, которые мы хотим игнорировать, можно использовать шаблоны поиска (считайте их упрощёнными регулярными выражениями):

• /___ — позволяет избежать рекурсивности — соответствует файлам только в текущей директории;
• __/ — соответствует всем файлам в указанной директории;
• *___ — соответствует всем файлам с указанным окончанием;
• ! — игнорирование файлов, попадающих под указанный шаблон;
• [__] — соответствует любому символу из указанных в квадратных скобках;
• ? — соответствует любому символу;
• /**/ — соответствует вложенным директориям, например a/**/d соответствует a/d, a/b/d, a/b/c/d и т. д.

Мы даже можем использовать шаблоны поиска при указании файла/папки в других командах. Например, git add src/*.css добавит все файлы .css в папке src.

Просмотр изменений

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

• -p показывает изменения в каждом коммите;
• --stat показывает сокращённую статистику для коммитов, например изменённые файлы и количество добавленных/удалённых строк в каждом их них;
• -n показывает n последних коммитов;
• --since=___ и --until=___ позволяет отфильтровать коммиты по промежутку времени, например --since="2019-01-01" покажет коммиты с 1 января 2019 года;
• --pretty позволяет указать формат логов (например, --pretty=oneline), также можно использовать --pretty=format для большей кастомизации, например --pretty=format:"%h %s";
• --grep и -S фильтруют коммиты с сообщениями/изменениями кода, которые содержат указанную строку, например, git log -S имя_функции позволяет посмотреть добавление/удаление функции;
• --no-merges пропускает коммиты со слиянием веток;
• ветка1..ветка2 позволяет посмотреть, какие коммиты из ветки 2 не находятся в ветке 1 (полезно при слиянии веток). Например, git log master..test покажет, каких коммитов из ветки test нет в master (о ветках поговорим чуть позже).
• --left-right ветка1...ветка2 показывает коммиты, которые есть либо в ветке 1, либо в ветке 2, но не в обеих; знак < обозначает коммиты из ветка1, а > — из ветка2. Обратите внимание: используется три точки, а не две;
• -L принимает аргумент начало,конец:файл или :функция:файл и показывает историю изменений переданного набора строк или функции в файле.

Другой полезной командой является git blame <файл>, которая для каждой строки файла показывает автора и контрольную сумму последнего коммита, который изменил эту строку. -L <начало>, <конец> позволяет ограничить эту команду заданными строками. Это можно использовать, например, для выяснения того, какой коммит привёл к определённому багу (чтобы можно было его откатить).

Наконец, есть команда git grep, которая ищет по всем файлам в истории коммитов (а не только в рабочей директории, как grep) по заданному регулярному выражению. Опция -n отображает соответствующий номер строки в файле для каждого совпадения, а --count показывает количество совпадений для каждого файла.

Примечание Не путайте git grep с git log --grep! Первый ищет по файлам среди коммитов, а последний смотрит на сообщения логов.

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

Пока что мы обсуждали использование Git только на локальной машине. Однако мы можем хранить историю коммитов удалённых репозиториев, которую можно отслеживать и обновлять. git remote -v выводит список удалённых репозиториев, которые мы отслеживаем, и имена, которые мы им присвоили.

При использовании команды git clone <url репозитория> мы не только загружаем себе копию репозитория, но и неявно отслеживаем удалённый сервер, который находится по указанному адресу и которому присваивается имя origin.

Наиболее употребляемые команды:

• git remote add <имя> <url> — добавляет удалённый репозиторий с заданным именем;
• git remote remove <имя> — удаляет удалённый репозиторий с заданным именем;
• git remote rename <старое имя> <новое имя> — переименовывает удалённый репозиторий;
• git remote set-url <имя> <url> — присваивает репозиторию с именем новый адрес;
• git remote show <имя> — показывает информацию о репозитории.

Следующие команды работают с удалёнными ветками:

• git fetch <имя> <ветка> — получает данные из ветки заданного репозитория, но не сливает изменения;
• git pull <имя> <ветка> — сливает данные из ветки заданного репозитория;
• git push <имя> <ветка> — отправляет изменения в ветку заданного репозитория. Если локальная ветка уже отслеживает удалённую, то можно использовать просто git push или git pull.

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

GitHub

GitHub — это платформа, которая хранит Git-репозитории на своих серверах, и основы распределенной системы управления версиями Git подразумевает умение с ней работать. Вы можете хранить свои удалённые репозитории или участвовать в Open Source проектах на GitHub.

Да, есть и другие платформы, но GitHub идеален для введения в Git и дополняет VCS новыми возможностями.

Например, вы можете сделать форк удалённого репозитория, то есть создать свою копию репозитория на севере GitHub. Это полезно в тех случаях, когда у вас нет прав на создание ветки в оригинальном репозитории. Когда вы воспользуетесь командой git clone, ваш локальный репозиторий будет отслеживать удалённый форк как origin, а оригинальный репозиторий как upstream.

После этого вам может понадобиться слить тематическую ветку вашего удалённого репозитория в основную ветку оригинального. Для этого вы можете создать новый Pull Request — запрос на внесение изменений, где GitHub проверяет наличие конфликтов прежде чем повзолить вам провести слияние. Зачастую существуют и другие проверки перед слиянием, например просмотр и одобрение кода или даже запуск тестов. В запросе можно обсудить код, а все коммиты, которые вы отправляете в удалённую тематическую ветку, будут автоматически добавлены в запрос, даже если он был создан до этих коммитов.

Работа с ветками

Ветвление — это возможность работать над разными версиями проекта: вместо одного списка с упорядоченными коммитами история будет расходиться в определённых точках. Каждая ветвь содержит легковесный указатель HEAD на последний коммит, что позволяет без лишних затрат создать много веток. Ветка по умолчанию называется master, но лучше назвать её в соответствии с разрабатываемой в ней функциональностью.

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

Команды:

• git branch <имя ветки> — создаёт новую ветку с HEAD, указывающим на HEAD. Если не передать аргумент <имя ветки>, то команда выведет список всех локальных веток;
• git checkout <имя ветки> — переключается на эту ветку. Можно передать опцию -b, чтобы создать новую ветку перед переключением;
• git branch -d <имя ветки> — удаляет ветку.

Локальный и удалённый репозитории могут иметь немало ветвей, поэтому когда вы отслеживаете удалённый репозиторий — отслеживается удалённая ветка (git clone привязывает вашу ветку master к ветке origin/master удалённого репозитория).

Привязка к удалённой ветке:

• git branch -u <имя удалённого репозитория>/<удалённая ветка> — привязывает текущую ветку к указанной удалённой ветке;
• git checkout --track <имя удалённого репозитория>/<удалённая ветка> — аналог предыдущей команды;
• git checkout -b <ветка> <имя удалённого репозитория>/<удалённая ветка> — создаёт новую локальную ветку и начинает отслеживать удалённую;
• git branch --vv — показывает локальные и отслеживаемые удалённые ветки;
• git checkout <удалённая ветка> — создаёт локальную ветку с таким же именем, как у удалённой, и начинает её отслеживать.

В общем, git checkout связан с изменением места, на которое указывает HEAD ветки, что похоже на то, как git reset перемещает общий HEAD.

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

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

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

Однако порой у вас есть незавершённые изменения, которые нельзя фиксировать. В такой ситуации их можно сохранить и «спрятать» с помощью команды git stash. Чтобы вернуть изменения, используйте git stash apply.

Возможно, вместо этого вы захотите стереть все внесённые изменения. В таком случае используйте команду git clean. Опция -d также удалит неотслеживаемые файлы. Совет: добавьте опцию -n, чтобы увидеть, что произойдёт при запуске git clean без непосредственного использования.

Слияние

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

Слиние включает в себя создание нового коммита, который основан на общем коммите-предке двух ветвей и указывает на оба HEAD в качестве предыдущих коммитов. Для слияния мы переходим на основную ветку и используем команду git merge <тематическая ветка>.

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

После открытия таких файлов вы увидите похожие маркеры разрешения конфликта:

			<<<<<<< HEAD:index.html
 Everything above the ==== is the version in master. 
 =======
 Everything below the ==== is the version in the test branch. 
 >>>>>>> test:index.html
		

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

Перемещение

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

Для перемещения используется команда git rebase <основная ветка> <тематическая ветка>, которая воспроизводит изменения тематической ветки на основной; HEAD тематической ветки указывает на последний воспроизведённый коммит.

Перемещение vs. слияние

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

Сценарий:

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

Перемещайте изменения только на вашей приватной локальной ветке — не перемещайте коммиты, от которых зависит ещё кто-то.

Откат коммитов — revert и reset

Похожие дебаты по поводу того, что лучше использовать, возникают, когда вы хотите откатить коммит. Команда git revert <коммит> создаёт новый коммит, отменяющий изменения, но сохраняющий историю, в то время как git reset <коммит> перемещает указатель HEAD, предоставляя более чистую историю (словно бы этого коммита никогда и не было). Важно отметить, что это также означает, что вы больше не сможете вернуться обратно к этим изменениям, например, если вы всё-таки решите, что отмена коммита была лишней. Чище — не значит лучше!

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

На этом основное введение в Git заканчивается, и начинается более глубокое изучение.

Интерактивная подготовка

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

• status — показывает для каждого файла краткое описание того, что (не)подготовлено;
• update — подготавливает отслеживаемые файлы;
• revert — убрать один или несколько файлов из подготовленной области;
• add untracked — подготавливает неотслеживаемый файл;
• patch — подготавливает только часть файла (полезно, когда вы, например, изменили несколько функций, но хотите разбить изменения на несколько коммитов). После выбора файла вам будут показаны его фрагменты и представлены возможные команды: Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]?. Можно ввести ?, чтобы узнать, что делает каждая команда;
• diff — показывает список подготовленных файлов и позволяет посмотреть изменения для каждого из них;
• quit — выходит из интерактивной консоли;
• help — показывает краткое описание каждой команды.

Символ * рядом с файлом означает, что команда изменит его статус (подготовлен/неподготовлен в зависимости от того, происходит ли обновление или откат). Если нажать Enter, не введя ничего ни в одном из под-меню команды, то все файлы перейдут в (не)подготовленное состояние. Создание патчей доступно в интерактивной консоли и через команду git add -p.

Правка истории

Для большего контроля над историей коммитов локальной ветки можно использовать команду git rebase -i HEAD~n, которая откроет интерактивную консоль для перемещения набора последних n коммитов, перечисленных в порядке от старых к новым (то есть в том порядке, в котором они будут перемещены). Таким образом вы можете «редактировать историю», однако помните, что оригинальные коммиты нельзя изменить, только переместить.

Вы можете поменять порядок коммитов, изменив порядок, в котором они перечислены.

Изменение сообщения/разбивка коммитов

Для указания коммита, который вы хотите изменить, используется команда edit. Затем, когда Git будет проводить перемещение, он остановится на этом коммите. После этого вы можете использовать git commit --amend, чтобы изменить сообщение или подготовить забытые файлы. Если вы хотите разделить коммит, после остановки введите git reset HEAD^ (в результате HEAD будет перемещён на один коммит назад и все изменённые в этом коммите файлы перейдут в статус неподготовленных). Затем вы сможете зафиксировать файлы в отдельных коммитах обычным образом.

После завершения редактирования введите git rebase --continue.

Перезапись нескольких коммитов

Иногда вам может потребоваться перезаписать несколько коммитов — в таких случаях можно использовать git filter-branch. Например, чтобы удалить случайно зафиксированный файл, можно ввести git filter-branch --tree-filter 'git rm -f <имя файла>' HEAD. Однако учтите, что при этом вся история перемещается.

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

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

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

Кроме слияния/перемещения всех коммитов в тематической ветке, вас может интересовать только определённый коммит. Допустим, у вас есть локальная ветка drafts, где вы работаете над несколькими потенциальными статьями, но хотите опубликовать только одну из них. Для этого можно использовать команду git cherry-pick. Чтобы получить определённые коммиты, из которых мы хотим выбирать, можно использовать git log <основная ветка>..<тематическая>.

Обратите внимание, что таким образом создаётся новый коммит, который только повторяет diff выбранного коммита (то есть разницу между этим коммитом и предыдущим), но не его состояние.

Закрепите введение в Git информацией о типичных ошибках в данной VCS и способах их решения.