Git инструкция шпаргалка для начинающих - Все инструкции и руководства по применению

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

Новичков часто пугает большое количество замысловатых команд и сложных аргументов. Но для начала все они и не нужны. Можно начать с изучения наиболее часто используемых команд, и после этого постепенно расширять свои знания. Именно так мы и поступим в этой статье. Поехали!

Основы

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

Для чего он нужен? Ну во-первых, чтобы отследить изменения, произошедшие с проектом, со временем. Проще говоря, мы можем посмотреть как менялись файлы программы, на всех этапах разработки и при необходимости вернуться назад и что-то отредактировать. Часто бывают ситуации, когда, во вполне себе работающий код, вам нужно внести определенные правки или улучшить какой-то функционал, по желанию заказчика. Однако после внедрения нововведений, вы с ужасом понимаете, что все сломалось. У вас начинается судорожно дергаться глаз, а в воздухе повисает немой вопрос: “Что делать?” Без системы контроля версий, вам надо было бы долго напряженно просматривать код, чтобы понять как было до того, как все перестало работать. С Гитом же, все что нужно сделать — это откатиться на коммит назад.

Во-вторых он чрезвычайно полезен при одновременной работе нескольких специалистов, над одним проектом. Без Гита случится коллапс, когда разработчики, скопировав весь код из главной папки и сделав с ним задуманное, попытаются одновременно вернуть весь код обратно.
Git является распределенным, то есть не зависит от одного центрального сервера, на котором хранятся файлы. Вместо этого он работает полностью локально, сохраняя данные в директориях на жестком диске, которые называются репозиторием. Тем не менее, вы можете хранить копию репозитория онлайн, это сильно облегчает работу над одним проектом для нескольких людей. Для этого используются сайты вроде github и bitbucket.

Установка

Установить git на свою машину очень просто:

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

Если вы новичок, клиент с графическим интерфейсом(например GitHub Desktop и Sourcetree) будет полезен, но, тем не менее, знать команды очень важно.

Настройка

Итак, мы установили git, теперь нужно добавить немного настроек. Есть довольно много опций, с которыми можно играть, но мы настроим самые важные: наше имя пользователя и адрес электронной почты. Откройте терминал и запустите команды:

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

Теперь каждое наше действие будет отмечено именем и почтой. Таким образом, пользователи всегда будут в курсе, кто отвечает за какие изменения — это вносит порядок.
Git хранит весь пакет конфигураций в файле .gitconfig, находящемся в вашем локальном каталоге. Чтобы сделать эти настройки глобальными, то есть применимыми ко всем проектам, необходимо добавить флаг –global. Если вы этого не сделаете, они будут распространяться только на текущий репозиторий.
Для того, чтобы посмотреть все настройки системы, используйте команду:

git config --list

Для удобства и легкости зрительного восприятия, некоторые группы команд в Гит можно выделить цветом, для этого нужно прописать в консоли:

git config --global color.ui true
git config --global color.status auto
git config --global color.branch auto

Если вы не до конца настроили систему для работы, в начале своего пути — не беда. Git всегда подскажет разработчику, если тот запутался, например:

Команда git —help — выводит общую документацию по git
Если введем git log —help — он предоставит нам документацию по какой-то определенной команде (в данном случае это — log)
Если вы вдруг сделали опечатку — система подскажет вам нужную команду
После выполнения любой команды — отчитается о том, что вы натворили
Также Гит прогнозирует дальнейшие варианты развития событий и всегда направит разработчика, не знающего, куда двигаться дальше

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

Создание нового репозитория

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

$ mkdir Desktop/git_exercise/
$ cd Desktop/git_exercise/
$ git init

Командная строка должна вернуть что-то вроде:

Initialized empty Git repository in /home/user/Desktop/git_exercise/.git/

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

Определение состояния

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 есть концепция области подготовленных файлов. Можно представить ее как холст, на который наносят изменения, которые нужны в коммите. Сперва он пустой, но затем мы добавляем на него файлы (или части файлов, или даже одиночные строчки) командой add и, наконец, коммитим все нужное в репозиторий (создаем слепок нужного нам состояния) командой 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

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

Фиксация изменений

Как сделать коммит

Представим, что нам нужно добавить пару новых блоков в html-разметку (index.html) и стилизовать их в файле style.css. Для сохранения изменений, их необходимо закоммитить. Но сначала, мы должны обозначить эти файлы для Гита, при помощи команды git add, добавляющей (или подготавливающей) их к коммиту. Добавлять их можно по отдельности:

git add index.html

git add css/style.css

или вместе — всё сразу:

git add .

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

git reset:

git reset css/style.css

Теперь создадим непосредственно сам коммит

git commit -m 'Add some code'

Флажок -m задаст commit message — комментарий разработчика. Он необходим для описания закоммиченных изменений. И здесь работает золотое правило всех комментариев в коде: «Максимально ясно, просто и содержательно обозначь написанное!»

Как посмотреть коммиты

Для просмотра все выполненных фиксаций можно воспользоваться историей коммитов. Она содержит сведения о каждом проведенном коммите проекта. Запросить ее можно при помощи команды:

git log

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

git show hash_commit

Ну а если вдруг нам нужно переделать commit message и внести туда новый комментарий, можно написать следующую конструкцию:

git commit --amend -m 'Новый комментарий'

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

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

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

1. Что такое удаленный репозиторий

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

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

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

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

2. Подключение к удаленному репозиторию

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

# This is only an example. Replace the URI with your own repository address.

$ git remote add origin https://github.com/tutorialzine/awesome-project.git

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

3. Отправка изменений на сервер

Сейчас самое время переслать наш локальный коммит на сервер. Этот процесс происходит каждый раз, когда мы хотим обновить данные в удаленном репозитории.
Команда, предназначенная для этого — push. Она принимает два параметра: имя удаленного репозитория (мы назвали наш 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

Эта команда немного похожа на git fetch, с той лишь разницей, что при помощи fetch мы импортируем коммиты в локальную ветку, а применив push, мы экспортируем их из локальной в удаленную. Если вам необходимо настроить удаленную ветку используйте git remote. Однако пушить надо осторожно, ведь рассматриваемая команда перезаписывает безвозвратно все изменения. В большинстве случаев, ее используют, чтобы опубликовать выгружаемые локальные изменения в центральный репозиторий. А еще ее применяют для того, чтобы поделиться, внесенными в локальный репозиторий, нововведениями, с коллегами или другими удаленными участниками разработки проекта. Подытожив сказанное, можно назвать git push — командой выгрузки, а git pull и git fetch — командами загрузки или скачивания. После того как вы успешно запушили измененные данные, их необходимо внедрить или интегрировать, при помощи команды слияния git merge.
В зависимости от сервиса, который вы используете, вам может потребоваться аутентифицироваться, чтобы изменения отправились. Если все сделано правильно, то когда вы посмотрите в удаленный репозиторий при помощи браузера, вы увидите файл hello.txt

4. Запрос изменений с сервера

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

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

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

Как удалить локальный репозиторий

Вам не понравился один из ваших локальных Git-репозиториев и вы хотите стереть его со своей машины. Для этого вам всего лишь надо удалить скрытую папку «.git» в корневом каталоге репозитория. Сделать это можно 3 способами:

Проще всего вручную удалить эту папку «.git» в корневом каталоге «Git Local Warehouse».
Также удалить, не устраивающий вас, репозиторий можно на github. Открываете нужный вам объект и переходите в пункт меню Настройки. Там, прокрутив ползунок вниз, вы попадете в зону опасности, где один из пунктов будет называться «удаление этого хранилища».
Последний метод удаления локального хранилища через командную строку, для этого в терминале необходимо ввести следующую команду:

cd repository-path/
rm -r .git

Ветвление

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

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

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

Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch <name>

$ git branch amazing_new_feature

Это создаст новую ветку, пока что точную копию ветки master.

2. Переключение между ветками

Сейчас, если мы запустим branch, мы увидим две доступные опции:

$ git branch
amazing_new_feature
* master

master — это активная ветка, она помечена звездочкой. Но мы хотим работать с нашей “новой потрясающей фичей”, так что нам понадобится переключиться на другую ветку. Для этого воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.

$ git checkout amazing_new_feature

В Git ветка — это отдельная линия разработки. Git checkout позволяет нам переключаться как между удаленными, так и меду локальными ветками. Это один из способов получить доступ к работе коллеги или соавтора, обеспечивающий более высокую продуктивность совместной работы. Однако тут надо помнить, что пока вы не закомитили изменения, вы не сможете переключиться на другую ветку. В такой ситуации нужно либо сделать коммит, либо отложить его, при помощи команды git stash, добавляющей текущие незакоммиченные изменения в стек изменений и сбрасывающей рабочую копию до HEAD’а репозитория.

3. Слияние веток

Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:

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

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

$ git checkout master

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

$ git merge amazing_new_feature

Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.

$ git branch -d awesome_new_feature

Если хотите создать копию удаленного репозитория — используйте git clone. Однако если вам нужна только определенная его ветка, а не все хранилище — после git clone выполните следующую команду в соответствующем репозитории:

git checkout -b <имя ветки> origin/<имя ветки>

После этого, новая ветка создается на машине автоматически.

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

git branch -d local_branch_name

где флажок -d являющийся опцией команды git branch — это сокращенная версия ключевого слова —delete, предназначенного для удаления ветки, а local_branch_name – название ненужной нам ветки.
Однако тут есть нюанс: удалить текущую ветку, в которую вы, в данный момент просматриваете — нельзя. Если же вы все-таки попытаетесь это сделать, система отругает вас и выдаст ошибку с таким содержанием:

Error: Cannot delete branch local_branch_name checked out at название_директории

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

Дополнительно

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

1. Отслеживание изменений, сделанных в коммитах

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

Вывод 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

Как вы можете заметить, идентификаторы довольно длинные, но для работы с ними не обязательно копировать их целиком — первых нескольких символов будет вполне достаточно. Чтобы посмотреть, что нового появилось в коммите, мы можем воспользоваться командой show [commit]

Вывод git show

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

Чтобы увидеть разницу между двумя коммитами, используется команда diff (с указанием промежутка между коммитами):

Вывод 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 difftool, так как эта команда запускает графический клиент, в котором наглядно сопоставляет все изменения.

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

Гит позволяет вернуть выбранный файл к состоянию на момент определенного коммита. Это делается уже знакомой нам командой checkout, которую мы ранее использовали для переключения между ветками. Но она также может быть использована для переключения между коммитами (это довольно распространенная ситуация для Гита — использование одной команды для различных, на первый взгляд, слабо связанных задач).
В следующем примере мы возьмем файл hello.txt и откатим все изменения, совершенные над ним к первому коммиту. Чтобы сделать это, мы подставим в команду идентификатор нужного коммита, а также путь до файла:

$ git checkout 09bd8cc1 hello.txt

3. Исправление коммита

Если вы опечатались в комментарии или забыли добавить файл и заметили это сразу после того, как закоммитили изменения, вы легко можете это поправить при помощи commit —amend. Эта команда добавит все из последнего коммита в область подготовленных файлов и попытается сделать новый коммит. Это дает вам возможность поправить комментарий или добавить недостающие файлы в область подготовленных файлов.
Для более сложных исправлений, например, не в последнем коммите или если вы успели отправить изменения на сервер, нужно использовать revert. Эта команда создаст коммит, отменяющий изменения, совершенные в коммите с заданным идентификатором.
Самый последний коммит может быть доступен по алиасу HEAD:

$ git revert HEAD

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

$ git revert b10cc123

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

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

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

// Use a for loop to console.log contents.
for(var i=0; i<arr.length; i++) {
console.log(arr[i]);
}

Тим предпочитает forEach:

// Use forEach to console.log contents.
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.

Система не смогла разрешить конфликт автоматически, значит, это придется сделать разработчикам. Приложение отметило строки, содержащие конфликт:

Вывод

<<<<<<< HEAD // Use a for loop to console.log contents. for(var i=0; i<arr.length; i++) { console.log(arr[i]); } ======= // Use forEach to console.log contents. arr.forEach(function(item) { console.log(item); }); >>>>>>> Tim's commit.

Над разделителем ======= мы видим последний (HEAD) коммит, а под ним — конфликтующий. Таким образом, мы можем увидеть, чем они отличаются и решать, какая версия лучше. Или вовсе написать новую. В этой ситуации мы так и поступим, перепишем все, удалив разделители, и дадим git понять, что закончили.

// Not using for loop or forEach.
// Use Array.toString() to console.log contents.
console.log(arr.toString());

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

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

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

5. Настройка .gitignore

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

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

Вот хорошие примеры файлов, которые нужно игнорировать:

Логи
Артефакты систем сборки
Папки node_modules в проектах node.js
Папки, созданные IDE, например, Netbeans или IntelliJ
Разнообразные заметки разработчика.

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

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

Символ слэша в конце некоторых линий означает директорию (и тот факт, что мы рекурсивно игнорируем все ее содержимое). Звездочка, как обычно, означает шаблон.

Git bash и git.io

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

Git Bash(Bourne Again Shell) — это приложение, являющееся эмулятором командной строки и предоставляющее, операционной системе, некоторые распространенные утилиты bash и собственно саму систему Git. Это терминал, используемый для взаимодействия с персональным компьютером, посредством письменных команд.
URL-адреса хранилищ на Гитхабе могут быть довольно длинными, из-за больших имен репозиториев и файлов. Работать с такими ссылками очень не удобно. Поэтому сайт github.io создал git.io — неплохой сервис по преобразованию этих длинных и беспорядочных URL-адресов в более короткие и понятные. Сайт был создан в 2011 году и вплоть до недавнего времени отлично справлялся со своими обязанностями. Однако в начале этого года компания Гитхаб, из-за участившихся попыток хакеров использовать сайт в злонамеренных целях, остановила работу сервиса, а чем известила пользователей в своем блоге. Разработчики популярного ресурса рекомендуют пользоваться другими URL-cutter’ами, пока работа сервиса не будет налажена.

Заключение.

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

Официальная документация, включающая книгу и видеоуроки – тут.
“Getting git right” – Коллекция руководств и статей от Atlassian – тут.
Список клиентов с графическим интерфейсом – тут.
Онлайн утилита для генерации .gitignore файлов – тут.

Оригинал статьи доступен на сайте http://tutorialzine.com

Другие статьи по теме

10 полезных Git команд, которые облегчат работу

Шпаргалка по Git, в которой представлены основные команды

Источник

Время на прочтение
9 мин

Количество просмотров 275K

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

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

30 основных команд, которые сделают из вас мастера Git

Как задать имя пользователя и адрес электронной почты
Кэширование учётных данных
Инициализация репозитория
Добавление отдельных файлов или всех файлов в область подготовленных файлов
Проверка статуса репозитория
Внесение изменений однострочным сообщением или через редактор
Просмотр истории коммитов с изменениями
Просмотр заданного коммита
Просмотр изменений до коммита
Удаление отслеживаемых файлов из текущего рабочего дерева
Переименование файлов
Отмена подготовленных и неподготовленных изменений
Изменение последнего коммита
Откат последнего коммита
Откат заданного коммита
Создание новой ветки и переход в неё
Просмотр списка веток
Удаление ветки
Слияние двух веток
Отображение журнала фиксации в виде графика для текущей или всех веток
Прекращение слияния при конфликте
Добавление удалённого репозитория
Просмотр удалённых URL-адресов
Получение дополнительных сведений об удалённом репозитории
Отправка изменений в удалённый репозиторий
Получение изменений из удалённого репозитория
Слияние удалённого репозитория с локальным
Отправка новой ветки в удалённый репозиторий
Удаление удалённой ветки
Использование перебазирования

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

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

git config --global user.name "Tara Routray"

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

git config --global user.email "dev@tararoutray.com"

2. Кэширование учётных данных

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

git config --global credential.helper cache

3. Инициализация репозитория

Создать пустой репозиторий Git или вновь инициализировать существующий можно параметром init. При инициализации он создаст скрытую папку. В ней содержатся все объекты и ссылки, которые Git использует и создаёт в истории работы над проектом.

git init

4. Добавление отдельных файлов или всех файлов в область подготовленных файлов

Добавить отдельный файл в область подготовленных файлов можно параметром add с указанием имени файла. Просто замените somefile.js на актуальное имя.

git add somefile.js

Кроме того, можно добавить все файлы и папки в эту область, предоставив wildcard . вместо имени файла:

git add .

5. Проверка статуса репозитория

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

git status

6. Внесение изменений однострочным сообщением или через редактор

При создании коммита в репозитории можно добавить однострочное сообщение с помощью параметра commit с флагом -m. Само сообщение вводится непосредственно после флага, в кавычках.

git commit -m "Your short summary about the commit"

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

git commit

7. Просмотр истории коммитов с изменениями

Просматривать изменения, внесённые в репозиторий, можно с помощью параметра log. Он отображает список последних коммитов в порядке выполнения. Кроме того, добавив флаг -p, вы можете подробно изучить изменения, внесённые в каждый файл.

git log -p

8. Просмотр заданного коммита

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

git show 1af17e73721dbe0c40011b82ed4bb1a7dbe3ce29

Также можно использовать сокращённый хеш.

git show 1af17e

9. Просмотр изменений до коммита

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

git diff

Для просмотра подготовленных изменений необходимо добавить флаг --staged.

git diff --staged

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

git diff somefile.js

10. Удаление отслеживаемых файлов из текущего рабочего дерева

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

git rm dirname/somefile.js

Можно также использовать маски файлов (например *.js) для удаления всех файлов, соответствующих критерию.

git rm dirname/*.html

11. Переименование файлов

Переименовать файл или папку можно параметром mv. Для него указывается источник source и назначение destination. Источник — реально существующий файл или папка, а назначение — существующая папка.

git mv dir1/somefile.js dir2

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

12. Отмена подготовленных и неподготовленных изменений

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

git checkout somefile.js

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

git reset HEAD somefile.js

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

git reset HEAD

13. Изменение последнего коммита

Внести изменения в последний коммит можно параметром commit с флагом --amend. Например, вы записали изменения, внесённые в ряд файлов, и поняли, что допустили ошибку в сообщении коммита. В этом случае можете воспользоваться указанной командой, чтобы отредактировать сообщение предыдущего коммита, не изменяя его снимок.

git commit --amend -m "Updated message for the previous commit"

Также можно вносить изменения в файлы, отправленные ранее. Например, вы изменили несколько файлов в ряде папок и хотите их записать как единый снимок, но забыли добавить в коммит одну из папок. Чтобы исправить такую ошибку, достаточно подготовить для фиксации остальные файлы и папки и создать коммит с флагами --amend и --no-edit.

git add dir1
git commit

# Here you forgot to add dir2 to commit, you can execute the
following command to amend the other files and folders.

git add dir2
git commit --amend --no-edit

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

Внимание! Не изменяйте публичные коммиты.

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

14. Откат последнего коммита

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

git revert HEAD

▍ Разница между revert и reset

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

У команды revert есть два крупных преимущества по сравнению с reset. Во-первых, она не меняет историю проекта и производит операцию, безопасную для коммитов. Во-вторых, её объектом выступает конкретный коммит, созданный в любой момент истории, а git reset всегда берёт за точку отсчёта текущий коммит. К примеру, если нужно отменить старый коммит с помощью git reset, придётся удалить все коммиты, поданные после целевого, а затем выполнить их повторно. Следовательно, команда git revert — гораздо более удобный и безопасный способ отмены изменений.

15. Откат заданного коммита

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

git revert 1af17e

16. Создание новой ветки и переход в неё

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

git branch new_branch_name

Но Git не переключится на неё автоматически. Для автоматического перехода нужно добавить флаг -b и параметр checkout.

git checkout -b new_branch_name

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

Можно просматривать полный список веток, используя параметр branch. Команда отобразит все ветки, отметит текущую звёздочкой (*) и выделит её цветом.

git branch

Также можно вывести список удалённых веток с помощью флага -a.

git branch -a

18. Удаление ветки

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

git branch -d existing_branch_name

Для принудительного удаления ветки используется флаг -D с заглавной буквой. В этом случае ветка будет удалена независимо от текущего статуса, без предупреждений.

git branch -D existing_branch_name

Вышеуказанные команды удаляют только локальную копию ветки. В удалённом репозитории она может сохраниться. Если хотите стереть удалённую ветку, выполните следующую команду:

git push origin --delete existing_branch_name

19. Слияние двух веток

Объединить две ветки можно параметром merge с указанием имени ветки. Команда объединит указанную ветку с основной.

git merge existing_branch_name

Если надо выполнить коммит слияния, выполните команду git merge с флагом --no-ff.

git merge --no-ff existing_branch_name

Указанная команда объединит заданную ветку с основной и произведёт коммит слияния. Это необходимо для фиксации всех слияний в вашем репозитории.

20. Отображение журнала фиксации в виде графика для текущей или всех веток

Просмотреть историю коммитов в виде графика для текущей ветки можно с помощью параметра log и флагов --graph --oneline --decorate. Опция --graph выведет график в формате ASCII, отражающий структуру ветвления истории коммитов. В связке с флагами --oneline и --decorate, этот флаг упрощает понимание того, к какой ветке относится каждый коммит.

git log --graph --oneline --decorate

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

git log --all --graph --oneline --decorate

21. Прекращение слияния при конфликте

Прервать слияние в случае конфликта можно параметром merge с флагом --abort. Он позволяет остановить процесс слияния и вернуть состояние, с которого этот процесс был начат.

git merge --abort

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

git reset

22. Добавление удалённого репозитория

Добавить удалённый репозиторий можно параметром remote add, указав shortname и url требуемого репозитория.

git remote add awesomeapp https://github.com/someurl..

23. Просмотр удалённых URL-адресов

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

git remote -v

Такая команда открывает доступ к интерфейсу управления удалёнными записями, которые хранятся в файле .git/config репозитория.

24. Получение дополнительных сведений об удалённом репозитории

Получить подробные сведения об удалённом репозитории можно с помощью параметра remote show с указанием имени репозитория — например, origin.

git remote show origin

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

25. Отправка изменений в удалённый репозиторий

Отправлять изменения в удалённый репозиторий можно параметром push с указанием имени репозитория и ветки.

git push origin main

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

26. Получение изменений из удалённого репозитория

Для загрузки изменений из удалённого репозитория используется параметр pull. Он скачивает копию текущей ветки с указанного удалённого репозитория и объединяет её с локальной копией.

git pull

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

git pull --verbose

27. Слияние удалённого репозитория с локальным

Слияние удалённого репозитория с локальным выполняется параметром merge с указанием имени удалённого репозитория.

git merge origin

28. Отправка новой ветки в удалённый репозиторий

Передать новую ветку в удалённый репозиторий можно параметром push с флагом -u, указав имя репозитория и имя ветки.

git push -u origin new_branch

29. Удаление удалённой ветки

Чтобы избавиться от удалённой ветки, используйте параметр push с флагом --delete, указав имя удалённого репозитория и имя ветки.

git push --delete origin existing_branch

30. Использование перебазирования

Для доступа к этой функции используйте параметр rebase с указанием имени ветки. Перебазирование — это процесс объединения или перемещения последовательности коммитов на новый родительский снимок.

git rebase branch_name

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

▍ Спасибо за внимание!

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

Источник

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

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

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

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

git clone	git commit	git diff	git branch	git merge
git init	git push	git log	git fetch	git rebase
git add	git status	git checkout	git pull	git revert

1. Команда git clone

Команда 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 выведет сообщение об ошибке и не склонирует репозиторий.

2. Команда git init

Команда 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.

3. Команда git add .

Команда 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 . очень полезна, когда вам нужно добавить много файлов в индекс одновременно. Однако, будьте осторожны, когда используете эту команду, особенно если вы работаете в большом проекте с множеством файлов. В некоторых случаях вам может потребоваться выбирать файлы для добавления в индекс более тщательно, чтобы избежать случайного добавления ненужных файлов.

4. Команда git commit

Команда 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.

5. Команда git push

Команда 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 и устанавливает отслеживание для этой ветки.

6. Команда 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».

7. Команда git diff

Команда 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.

8. Команда git log

Команда 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» в своих комментариях.

9. Команда git checkout

Команда 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» и выбрать, какие из них восстановить.

10. Команда git branch

Команда 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 позволяет управлять ветками в репозитории и помогает организовать работу в команде. Она также помогает контролировать историю изменений в проекте.

11. Команда git fetch

Команда 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.

12. Команда git pull

Команда 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

13. Команда git merge

Команда 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

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

14. Команда git rebase

Команда 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 используется для корректной обработки коммитов слияния.

15. Команда git revert

Команда 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 через терминал — это обязательная часть практики фронтендера. Однако для начинающих разработчиков этот инструмент может показаться сложным. Чтобы вам было проще учиться, мы собрали основные команды для работы с Git.

☝ В некоторых командах мы будем писать URL-адрес удалённого репозитория и название проекта в квадратных скобках, вот так — [ссылка на удалённый репозиторий]. Мы делаем это только для наглядности. Вам квадратные скобки ставить не нужно.

Первоначальная настройка Git

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

Указать имя пользователя — git config --global user.name "Ivan Ivanov". Задаёт имя пользователя, от которого будут идти коммиты. Вместо Ivan Ivanov нужно написать свои данные на латинице. Если имя состоит из одного слова, кавычки можно не ставить.

Указать электронную почту — git config --global user.email "mail@gmail.com". Вместо mail@gmail.com нужно указать вашу почту. Обратите внимание, она должна совпадать с той, на которую зарегистрирован аккаунт в Гитхабе.

Посмотреть настройки — git config --list. Параметры можно посмотреть и в конфигурационном файле, но этот способ быстрее.

Работа с репозиторием

Создать репозиторий — git init. Инициализирует пустой репозиторий.

Склонировать удалённый репозиторий — git clone [ссылка на удалённый репозиторий]. Проект появится в директории, где вы находились в момент клонирования.

Связать удалённый и локальный репозитории — git remote add origin [ссылка на удалённый репозиторий].

Работа с изменениями

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

Подтянуть изменения — git pull. Подтягивает в локальный репозиторий последнюю версию проекта. Будьте внимательны, вызов этой команды сотрёт все незафиксированные изменения. Иногда после ввода этой команды появляется конфликт.

Как решать проблемы в Git

Посмотреть статус файлов — git status. Вы увидите, какие файлы изменили, удалили или добавили в проект. При этом статус «Закоммичен» не отобразится.

Добавить файлы в индекс — git add [название файла]. После ввода этой команды вы можете сделать коммит.

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

Сделать коммит — git commit -m "Комментарий к коммиту" — фиксирует изменения. До выполнения этой команды локальные изменения никуда не запишутся.

Нужно правильно разбивать изменения и давать полные комментарии к коммитам. Подробнее об этом читайте в статье «Как оформлять коммиты».

Посмотреть историю коммитов — git log. Выводит список всех коммитов. У этой команды есть разные опции, самая используемая из них — --oneline. Она показывает хеш в укороченном формате, ветку, в которой сделан коммит, а также текст коммита. Чтобы использовать эту опцию (как и любую другую), нужно добавить её после команды: git log--oneline.

Запушить изменения — git push. Отправляет все зафиксированные изменения с локального репозитория в удалённый. Это одна из самых важных команд, ведь все вышеописанные действия производятся в локальной копии репозитория. Когда вы закончите работу, эту копию нужно будет отправить в удалённый репозиторий. Только так другие участники процесса смогут получить актуальную версию.

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

Работая с Git, приходится постоянно создавать и перемещаться по веткам. А иногда ветки нужно удалять или сливать.

☝ Здесь мы для примера используем branch-name. Вам при вводе команды нужно указать название вашей ветки.

Создать ветку — git switch --create branch-name. Добавляет новую ветку с названием branch-name и автоматически переключает на неё.

Переключить ветку — git switch branch-name. Вы перейдёте на уже созданную ветку branch-name.

Для создания и переключения веток также можно использовать git checkout. Эта команда появилась раньше, у неё есть множество дополнительных функций. Например, она может восстанавливать изменения в коммите. Как раз из-за такого разнообразия задач разработчики решили создать отдельную команду для переключения между ветками — git switch. Вы можете использовать любую из команд, однако git switch доступна только в версиях от 2.23.

Посмотреть все локальные ветки — git branch.

Переименовать ветку — git branch -m [старое-название-ветки] [новое-название-ветки] — переименовывает ветку. Названия нужно писать на латинице.

Отправить ветку — git push origin [branch-name] — отправляет ветку в удалённый репозиторий.

Удалить ветки — git branch --delete [branch-name]. Команда удаляет ветку [branch-name] в локальном репозитории. Если нужно избавиться от ветки в удалённом репозитории, используйте git push --delete origin [branch-name].

Влить ветки — git merge [branch-name]. Вливает ветку branch-name в ветку, в которой вы находитесь.

Перебазировать коммиты — git rebase [branch-name]. Перебазирует коммиты из ветки, в которой вы находитесь, в ветку [branch-name].

Создать точную копию коммитов — git cherry-pick. Команду часто совмещают с git merge и git rebase, чтобы сохранить линейную историю коммитов. То есть создаётся точная копия коммитов, выполняется перебазирование и слияние веток.

Откладывание и удаление

Отложить изменения — git stash push. Откладывает изменения, чтобы вы, например, могли срочно перейти к другой задаче. Чтобы отложить только часть изменений, используйте git stash --patch.

Вернуть отложенные изменения — git stash pop.

Отменить изменения, не добавленные в индекс — git restore [название файла]. Удалит изменения в одном файле. Чтобы удалить изменения во всех файлах, используйте git restore :/.

Отменить изменения, добавленные в индекс — git reset --hard. Возвращает изменения из индекса и полностью их отменяет.

Удалить коммит — git revert [195dfb0]. Вместо [195dfb0] указывается хеш коммита, его можно узнать с помощью команды git log.

Отменить слияние с конфликтом — git merge --abort. Используется, когда нет времени решать конфликт прямо здесь и сейчас.

Удалить лишнее — git clean. Команда «наводит чистоту» — удаляет неотслеживаемые файлы из рабочего каталога.

✅ Больше информации о работе с Git и практические навыки вы получите на курсе о Git и GitHub.

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.

ТелеграмПодкастБесплатные учебники

Источник

Шпаргалка по командам git
Что делать, когда под руками нет SourceTree

Основной сценарий

Шаг 1

У нас есть задача (issue), которую мы планируем сделать. В центральном репозитории создаём ветку для решения задачи. Например, для задачи с номером 234 создаём ветку features/issue-234.

Примечание: префикс features/ влияет на отображение > веток в таких графических
клиентах, как Git Extensions и
Sourcetree. Ветки, в чьих именах встреыется символ /
выглядят как файлы в каталогах. Так, ветка features/issue-234 выглядит как ветка
issue-234 в каталоге features.

Так удобно группировать ветки.

Шаг 2

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

Сначала скачиваем из удалённого репозитория изменения, включая новые ветки

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

Создаём локальную ветку, которая указывает на удалённую ветку

git checkout -b features/issue-234 origin/features/issue-234

или, короче

git checkout -t origin/features/issue-234

Шаг 3

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

Прежде, чем фиксировать, смотрим, что успели сделать.

Untracked — git не отслеживает изменения в этих файлах и не хранит их.
Changes not staged for commit — git отлеживает и хранит эти файлы. Сейчас эти файлы изменены,
но git не будет сохранять эти изменения при фиксации.
Changes to be committed — файлы изменены и git сохранит эти изменения при следующей фиксации.

Помечаем для фиксации файлы file₁..fileₙ.

Помечаем для фиксации все файлы в текущем каталоге и его подкаталогах. Помеченными окажутся в том числе все новые файлы.

Фиксируем все файлы, помеченные для фиксации. Git попросит ввести комментарий.

Команда git commit -a работает также, как git add . и git commit вместе, за тем исключением, что новые файлы не будут зафиксированы.

Команда git commit -m "Комментарий к коммиту" фиксирует изменения с указанным комментарием, не запуская внешний редактор.

Отправляем изменения в центральный репозиторий.

Откат изменений

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

git checkout -- file₁ ... fileₙ

Либо вы можете отказить изменения во всех файлах в каталоге и его подкаталогах:

Если вы зафиксировали изменения, но ещё не отправили их в удалённый репозиторий, откатите последнюю фиксацию:

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

Если вы случайно добаили к списку отслеживаемых файлов что-то, что не надо отслеживать, например, временные файлы *.tmp или результаты компиляции *.obj, вы можете удалить их из репозитория:

git rm --cached file₁ ... fileₙ

Без флага --cached git удалит файлы и в репозитории, и на диске. Эта же команда используется, если вы обновили .gitignore и хотите удалить из репозитория файлы, которые соответствуют новым правилам .gitignore:

git rm --cached .
git add .

Первая команда удалит из репозитория всех файлы (оставив их на диске), а вторая снова добавит их в репозиторий. При добавлении git проверит файлы на соответствие шаблонам .gitignore.

Удалить с диска новые файлы

Шаг 4

Решив задачу мы должны слить все изменения в основную ветку — master или main. Это делается через pull request в центральном репозитории. Ставим галочку удалить исходную ветку после слияния, чтобы не пришлось удалять эти ветку вручную.

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

«Затягиваем» в неё изменения из центрального репозитория.

После изменения можно слить с текущей веткой:

После слияния в истории репозитория остаются «следы» — коммиты сначла расходятся, потом снова сходятся. Можно избавиться от следов, склеив все коммиты в одну ветку:

Вместо команд:

можно использовать:

Вместо команд:

можно использовать:

Синхронизация веток

Смотрим, какие ветки живы локально, но при этом удалены на сервере.

Удаляем ветки, которые показала предыдущая команда.

git branch -d features/issue-234

Удаляем из центрального репозитория ветки, которых нет у нас:

Вливаем изменения из центрального репозитория

Если в ветке master появились изменения, мы можем влить в нашу ветку, чтобы в будущем упростить pull request. Переключаемся на ветку master, загружаем обновления, переключаемя на рабочую ветку, сливаемся с master и выгружаем результат в центральный репозиторий. Если конфликтов не было, pull request пройдёт без проблем.

git checkout master
git pull
git checkout features/issue-234
git merge master
git push

Источник