Какая инструкция git позволяет зафиксировать изменения

Запись изменений в репозиторий

Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта.
Вам нужно делать некоторые изменения и фиксировать «снимки» состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.

Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые).
Отслеживаемые файлы — это те файлы, которые были в последнем снимке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту.
Если кратко, то отслеживаемые файлы — это те файлы, о которых знает Git.

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

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

Картинка с сайта: git-scm.com

Рисунок 8. Жизненный цикл состояний файлов

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean

$ echo 'My Project' > README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    README

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

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)

    new file:   README

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

$ vim CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

$ git status -s
 M README
MM Rakefile
A  lib/git.rb
M  lib/simplegit.rb
?? LICENSE.txt

$ cat .gitignore
*.[oa]
*~

# Исключить все файлы с расширением .a
*.a

# Но отслеживать файл lib.a даже если он подпадает под исключение выше
!lib.a

# Исключить файл TODO в корневом каталоге, но не файл в subdir/TODO
/TODO

# Игнорировать все файлы в каталоге build/
build/

# Игнорировать файл doc/notes.txt, но не файл doc/server/arch.txt
doc/*.txt

# Игнорировать все .txt файлы в каталоге doc/
doc/**/*.txt

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
 Please include a nice description of your changes when you submit your PR;
 if we have to read the whole diff to figure out why you're contributing
 in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your changes into comprehensive chunks if you patch is
+longer than a dozen lines.

 If you are starting to work on a particular area, feel free to submit a PR
 that highlights your work in progress (and note in the PR title that it's

$ git diff --staged
diff --git a/README b/README
new file mode 100644
index 0000000..03902a1
--- /dev/null
+++ b/README
@@ -0,0 +1 @@
+My Project

$ git add CONTRIBUTING.md
$ echo '# test line' >> CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   CONTRIBUTING.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 643e24f..87f08c8 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -119,3 +119,4 @@ at the
 ## Starter Projects

 See our [projects list](https://github.com/libgit2/libgit2/blob/development/PROJECTS.md).
+# test line

$ git diff --cached
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
 Please include a nice description of your changes when you submit your PR;
 if we have to read the whole diff to figure out why you're contributing
 in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your changes into comprehensive chunks if you patch is
+longer than a dozen lines.

 If you are starting to work on a particular area, feel free to submit a PR
 that highlights your work in progress (and note in the PR title that it's

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
# Changes to be committed:
#	new file:   README
#	modified:   CONTRIBUTING.md
#
~
~
~
".git/COMMIT_EDITMSG" 9L, 283C

$ git commit -m "Story 182: fix benchmarks for speed"
[master 463dc4f] Story 182: fix benchmarks for speed
 2 files changed, 2 insertions(+)
 create mode 100644 README

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

no changes added to commit (use "git add" and/or "git commit -a")
$ git commit -a -m 'Add new benchmarks'
[master 83e38c7] Add new benchmarks
 1 file changed, 5 insertions(+), 0 deletions(-)

$ rm PROJECTS.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    PROJECTS.md

no changes added to commit (use "git add" and/or "git commit -a")

$ git rm PROJECTS.md
rm 'PROJECTS.md'
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    deleted:    PROJECTS.md

$ git mv file_from file_to

$ git mv README.md README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

$ mv README.md README
$ git rm README.md
$ git add README

История развития систем контроля версий берет начало в далеком 1972 году, когда компания Bell Labs разработала первую систему управления версиями под названием Source Code Control System, или сокращенно SCCS. Программа была популярна вплоть до 1982 года, когда была разработана новая система под названием Revision Control System (RCS). Дальнейшее развитие систем контроля версий продолжилось в 2000 году, когда были выпущены сразу две программы: Subversion (более известная под именем SVN) и BitKeeper. Обе программы были выпущены с целью заменить морально устаревшие утилиты, такие как CVS и RCS. Однако настоящий прорыв произошел в 2005 году, когда появился Git, который снискал популярность среди разработчиков и IT-индустрии в целом. Сегодня Git стал инструментом, де-факто выступающим в качестве основного инструмента контроля версий, а также послужил основой для создания таких веб-сервисов, как GitHub, GitLab и Bitbucket.

В Git используется контентно-адресуемая система для хранения данных, основанная на адресации по контрольной сумме (она же хеш-сумма). Хеш-сумма выступает в роли уникального идентификатора содержимого пользовательских данных — иными словами, адресом каждого объекта является хеш его содержимого.

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

Git оперирует тремя типами объектов: файл, дерево и «коммит» (commit). В объект «файл» вносятся необходимые изменения; дерево — иерархия файлов в репозитории, которая создает связь между директориями и содержащимися в них файлами. Под «коммитом» понимают метод фиксации изменений в файлах.

В Git используются два типа репозиториев: локальный и удаленный. Локальный репозиторий хранится на устройстве пользователя. Удаленный репозиторий располагается на удаленном устройстве — например на отдельном компьютере. Большинство действий в Git выполняются локально, так как это не централизованная система.

Установка Git

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

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

Для пользователей Windows присутствуют разнообразные программы с графическим интерфейсом, включая такие, как GitHub Desktop, Sourcetree, GitKraken Desktop. С полным списком программ для Windows можно ознакомиться по ссылке.

Для пользователей macOS можно воспользоваться менеджером пакетов Homebrew или MacPorts, а также одной из десятков различных программ с графической оболочкой, включая такие, как GitUp, Gitfox, SnailGit, GitFinder и многие другие. Ознакомиться с инструкцией по установке Git на macOS можно по ссылке.

Отдельно стоит выделить, что в некоторых IDE, например, VS Code, Xcode, PyCharm, PhpStorm, WebStorm, Git уже предустановлен и его можно использовать “из-коробки”.

vds

Основы Git

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

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

Настроим базовые параметры Git, а именно зададим имя пользователя, а также адрес электронной почты. Данная информация будет отображена в каждом коммите для установления личности пользователя. Как правило, без настройки имени и адреса электронной почты нельзя взаимодействовать с Git и его функционалом. Зададим имя пользователя. выполнив в терминале команду (где Alex — это имя пользователя):

git config --global user.name "Alex"

Далее зададим адрес электронной почты, используя команду (где alex_mailbox@mail.com — это адрес электронной почты пользователя):

git config --global user.email alex_mailbox@mail.com

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

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

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

Создадим новую директорию:

mkdir stage-file-for-futher-projeect

Далее переходим в созданную директорию:

cd  stage-file-for-futher-projeect

И выполним команду:

git init

Картинка с сайта: timeweb.cloud

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

Картинка с сайта: timeweb.cloud

Копирование Git-репозитория

Также присутствует возможность скопировать уже существующий репозиторий. Такие репозитории называются удаленными. Обычно такую возможность используют при работе с такими веб-сервисами, как GitHub и GitLab. Чтобы скопировать удаленный репозиторий, необходимо знать его URL. Для скачивания используют команду git clone. В приведенном примере мы скачаем репозиторий с исходным кодом утилиты curl:

git clone https://github.com/curl/curl.git

Картинка с сайта: timeweb.cloud

После скачивания нам будет доступна папка с исходным кодом curl:

Картинка с сайта: timeweb.cloud

Состояние репозитория Git

Одной из главных функциональных особенной Git является состояние (или статус) репозитория. Статус используется не только для проверки состояния репозитория, но и для того, чтобы узнать статус индексного раздела. Рассмотрим данную команду, используя репозиторий curl, скачанный ранее. При выполнение команды git status после того, как был скачан репозиторий, в ответ будет выведено сообщение:

Картинка с сайта: timeweb.cloud

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

Теперь попробуем создать в текущем каталоге curl новый файл:

touch new-test-file.txt

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

git status

Картинка с сайта: timeweb.cloud

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

git add new-test-file.txt

Статус репозитория был изменен. Проверим:

git status

Картинка с сайта: timeweb.cloud

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

git commit -m "Added new-test-file.txt"

Картинка с сайта: timeweb.cloud

и убедимся что статус репозитория был также изменен:

git status

Картинка с сайта: timeweb.cloud

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

Добавление файлов

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

git add file1.txt

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

git add .

git add поддерживает работу с символами регулярных выражений.

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

git add *.txt

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

git reset file2.txt

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

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

Коммит снабжается сообщением (комментарием), в котором указывается, что за изменения были внесены. Выполним коммит, добавив к нему сообщение:

git commit -m "Added first file"

Картинка с сайта: timeweb.cloud

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

Git ведет историю коммитов. Для просмотра истории воспользуйтесь командой git log:

git log

Картинка с сайта: timeweb.cloud

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

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

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

Создадим новую ветку new_function:

git branch new_function

 Выведем все доступные ветки:

git branch

Картинка с сайта: timeweb.cloud

git branch выводит только те ветки, которые доступны локально. Для вывода всех веток (локальных и удаленных) необходимо использовать:

git branch -a

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

git checkout new_function

Картинка с сайта: timeweb.cloud

Создадим новый файл:

touch new-branch-file.txt

И добавим его:

git add new-branch-file.txt

Выполняем коммит:

git commit -m "Added new-branch-file.txt file"

Файл будет отображаться только в ветке new_function:

Картинка с сайта: timeweb.cloud

Убедимся, переключившись обратно на ветку main:

git checkout main

Картинка с сайта: timeweb.cloud

Как можно увидеть, ранее созданный файл new-branch-file.txt в ветке new_function недоступен в ветке main.

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

Ветки можно удалять. Для этого используется команда git branch -d. При удалении ветки необходимо учитывать, что нельзя удалить текущую ветку. При попытке удаления текущей ветки Git вернет ошибку:

git branch -d new_function

Картинка с сайта: timeweb.cloud

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

git checkout main

Далее ветку можно удалить:

git branch -d new_function

Картинка с сайта: timeweb.cloud

Если удаляемая ветка не была объединена, то при удаление такой ветки будет выведено предупреждение:

Картинка с сайта: timeweb.cloud

Чтобы удалить такую ветку, необходимо использовать опцию -D:

git branch -D new_function

Картинка с сайта: timeweb.cloud

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

Особенностью использования веток является изоляция внесенных изменений — изменения доступные в одной ветке автоматически не появляются в других. В Git существует процесс слияния двух веток, который называется merge request. При слиянии все изменения, которые были внесены в одну ветку, переносятся в другую. Рассмотрим на примере слияния изменений из ветки new_function в ветку main. 

1) Создаем новую ветку:

git branch new_function

И переключаемся на нее:

git checkout new_function

2) Создаем новый файл:

touch new-branch-file.txt

3) Добавляем созданный файл в индекс:

git add new-branch-file.txt

4) Делаем коммит:

git commit -m "Added new-branch-file.txt file"

5) Переключаемся на ветку main:

git checkout main

6) Выполняем merge request:

git merge new_function

Картинка с сайта: timeweb.cloud

Теперь ранее внесенные изменения в ветке new_function появились в ветке main:

Картинка с сайта: timeweb.cloud

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

Ранее мы работали только с локальными репозиториями. Но Git поддерживает работу и с удаленными репозиториями. Удаленный репозиторий — это репозиторий, который хранится на сервере. 

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

Локальный репозиторий можно подключить к удаленному репозиторию с помощью git remote add. Рассмотрим подключение на примере сервиса GitHub.

1) Открываем GitHub, авторизуемся в аккаунте и создаем новый репозиторий:

Картинка с сайта: timeweb.cloud

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

git remote add origin https://github.com/AlexFromMoscow6/demo-repo.git

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

Отправим ранее добавленные изменения в удаленный репозиторий при помощи git push: 

git push -u origin main

Картинка с сайта: timeweb.cloud

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

Переходим в GitHub и смотрим, чтобы файлы были опубликованы:

Картинка с сайта: timeweb.cloud

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

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

Минимальный набор команд git для начала работы с проектом

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

1) Инициализируем репозиторий Git:

git init

Картинка с сайта: timeweb.cloud

2) Добавляем все файлы (символ точки), которые располагаются в репозитории:

git add .

Картинка с сайта: timeweb.cloud

3) Делаем коммит:

git commit -m "Initial commit"

Картинка с сайта: timeweb.cloud

4) Переходим в веб-версию GitHub, авторизуемся в своем аккаунте и создаем новый репозиторий (зеленая кнопка New):

Картинка с сайта: timeweb.cloud

Задаем имя репозиторию и выбираем тип репозитория (публичный, который будет доступен для всех пользователей, или приватный, доступ до которого будет только у владельца репозитория; доступ для остальных пользователей необходимо будет настраивать отдельно):

Картинка с сайта: timeweb.cloud

5) Возвращаемся в терминал и подключаем наш ранее созданный локальный репозиторий к удаленному: 

git remote add origin https://github.com/AlexFromMoscow6/simple-js-app.git

6) Наконец, отправляем изменения в удаленный репозиторий:

git push -u origin main

Картинка с сайта: timeweb.cloud

Далее возвращаемся на страницу репозитория в GitHub и проверяем, что все файлы были добавлены в репозиторий:

Картинка с сайта: timeweb.cloud

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

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

Что такое commit?

Коммит в Git — это одна из основных операций в системе контроля версий Git. Commit (в переводе с английского «зафиксировать») означает сохранение изменений в файловой системе и создание новой ревизии, которая отражает состояние проекта на данный момент.

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

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

Для понимания, что такое коммит, рассмотрим основные элементы такого сохранения:

• Идентификатор. Каждый коммит имеет уникальный хеш-код. Он формируется на основе содержимого коммита и его «родителей», что обеспечивает ему уникальность и неизменяемость.
• Автор и метаинформация. Коммит содержит информацию об авторе, включая имя и адрес электронной почты. Также может быть указан коммитер (человек, сделавший последнее сохранение) — например, если происходит изменение прав собственности на код. Помимо этого, метаинформация содержит дату и время создания коммита и сообщение-комментарий, в котором разработчик описывает внесенные изменения.
• Содержимое файлов. Коммит включает снимок текущего состояния репозитория, в том числе все измененные, добавленные или удаленные данные. Внутри него хранится информация о каждом файле, включая его имя, содержимое и режим доступа.
• Дополнительные метаданные. Внутри коммита могут храниться теги, указывающие на специфические моменты в истории репозитория, или ссылки на другие ветки.

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

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

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

Как изменить коммит в Git?

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

• Команда git commit -amend. Если нужно изменить последний коммит, но вы не внесли новые изменения, введите команду git commit -amend в терминале. Она открывает текстовый редактор по умолчанию, где можно отредактировать сообщение коммита. После внесения изменений просто сохраните файл. Если вам нужно добавить новые правки к последнему коммиту, сначала внесите их в свои файлы, затем выполните команду git add, чтобы указать их в индексе. Затем запустите команду git commit -amend, которая объединит новые правки с предыдущим коммитом. 
• Команда git rebase -i. Для изменения коммита, который не является последним, введите команду git rebase -i HEAD~N, где N — количество сохранений до того, который вы хотите изменить. После выполнения этой команды откроется текстовый редактор, где вы увидите список коммитов. Найдите нужное вам сохранение и замените слово «pick» (выполнять) перед коммитом на «edit» (редактировать). Сохраните файл и закройте редактор. Теперь Git автоматически переключится на коммит, который вы хотите скорректировать. Внесите нужные изменения в ваш файл, затем используйте команду git add, чтобы добавить изменения в индекс, а затем git commit -amend, чтобы исправить коммит. 

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

Преимущества коммитов

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

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

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

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

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

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

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

Недостатки коммитов

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

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

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

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

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

Картинка с сайта: habr.com

Из этой статьи вы узнаете

• Зачем нужны системы контроля версий

• Откуда взялся Git

• Как создать свой репозиторий на GitHub и внести в него изменения

• Что такое fork, branch и другие интересные слова из мира Git

• Как создать свой Pull Request

Вступление

Бывает, что начинающие разработчики проблематично осваивают Git и не с первого захода понимают логику работы сервиса. Но стоит создать пару репозиториев или, ещё лучше, погрузиться в реальную историю по установке стартапа на рельсы DevOps, как работа с ветками станет дружелюбной, а PR и MR больше не вызовут путаницы. Ошибки в любом случае появятся, но вы будете к ним готовы!

Начало

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

Первое и самое просто решение — «А давайте перед каждым изменением сохранять копию программы (просто копировать папку с кодом)?»

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

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

Про Git

Существует несколько систем контроля версий: Git, Subversion, Team Foundation Server, Mercurial. Сегодня познакомимся с Git — самой популярной из них, по скромному признанию более 90% разработчиков.

Git появился 7 апреля 2005 года и был создан для управления разработкой ядра Linux. Кстати, создал его тот самый Линус Торвальдс, а сегодня его развитием и поддержкой занимается Дзюн Хамано.

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

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

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

GitHub — крупнейший веб-сервис, который позволяет заниматься совместной разработкой с использованием Git и сохранять изменения на своих серверах. На самом деле функциональность GitHub намного больше, но сейчас нас интересует только совместная разработка и история изменений. Ещё есть Gitlab, Bitbucket и другие, но мы будем использовать GitHub как самый популярный в настоящее время.

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

Займёмся предполётной подготовкой.

Для начала зарегистрируйтесь на GitHub: задайте логин, почту и придумайте пароль. После «Создать аккаунт» не забудьте проверить почту и подтвердить её (опрос от Github после подтверждения почты можно пропустить).

Картинка с сайта: habr.com

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

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

GitHub поддерживает безопасность за счёт двух сетевых протоколов, HTTPS и SSH, и вся работа с сервисом происходит через один из них.

Работать с GitHub будем через терминал по SSH. Для этого один раз сгенерируем специальные ключи и добавим один из них в наш аккаунт на GitHub.

Можно работать и через HTTPS, но нужно будет каждый раз вводить пароль и специальный token.

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

При подключении используется пара ключей — открытый (публичный, public) и закрытый (приватный, private). Пользователь создаёт пару ключей при помощи специальной команды и сохраняет закрытый ключ у себя, а открытый кладёт на сервер (в нашем случае на GitHub). А работает это всё благодаря асимметричному шифрованию.

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

Давайте создадим пару ключей и добавим открытый ключ на GitHub.

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

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

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

$ ssh-keygen
Generating public/private rsa key pair.
# путь до ключей, в скобках путь по умолчанию
Enter file in which to save the key (/Users/ifireice/.ssh/id_rsa):  
# пароль для ключей, при задании пароля в консоли не отображается ничего, даже звёздочки
# если нажать Enter, ничего не вводя, пароль будет пустым
Enter passphrase (empty for no passphrase):
# повторите пароль
Enter same passphrase again:
# после появится сообщение такого вида
Your identification has been saved in /Users/ifireice/.ssh/id_rsa
Your public key has been saved in /Users/ifireice/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:Zu+HkZPC4ZP0veRmVjuKgylVvljHBNO8mHs+ieFFPvs ifireice@ifireice-osx
The key's randomart image is:
+---[RSA 3072]----+
|           o     |
|          o o    |
|           = .   |
|        o + +    |
|       +S* X     |
|       oB.@ X .  |
|       . O.# * . |
|      . +.*.% o  |
|       .  o*.+E. |
+----[SHA256]-----+

Бинго, ключи сгенерированы: в заданной директории появятся два файла, id_rsa и id_rsa.pub.

Теперь надо добавить публичный ключ в аккаунт на GitHub:

# выведите содержимое публичного ключа в консоль
$ cat ~/.ssh/id_rsa.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDDJfHIi73sKd6cqm3RwKuY1zl46aAaE6X9Gp
/6zJiY3BiJj95oJjPdpfpPhVFWLIbmT8zFAtOLbX9N4C3b0enHUzgMacP/Kl4AbrAkhLqaua9iD
VNxxiTVxADG1M5525oc/eAvx7y0pXIb9ouWdYJSKa8/TUYFhWlCzV2quY9SA0FaMs7eY41+KWYpG.....
tA0oGxv+7WmXQmQzleLIRG13KQ+VAbL2vabdPcRoGuZavh0smOr/GtVSnLdspZ5RgONMSPWlF2I1YHMR
Q7CIKPs= ifireice@ifireice-osx
$

Скопируйте ключ от символов ssh-rsa и до конца файла и вставьте его в ваш аккаунт на GitHub.

Картинка с сайта: habr.com

Картинка с сайта: habr.com

Картинка с сайта: habr.com

Картинка с сайта: habr.com

Ну что, с настройкой GitHub пока закончили, осталось установить Git на компьютер. Сделать это можно по официальной инструкции (выберите пункт для вашей ОС).

Терминология

Самое время пополнить ваш Git-словарик, прежде чем создадим первый Pull Request.

Репозиторий (repository) — директория проекта, который отслеживается Git. В директории хранится проект, история изменений и мета-информация проекта (в скрытой директории .git).

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

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

Ветка (branch) — последовательность коммитов. По сути — ссылка на последний коммит в этой ветке. Ветки не зависят друг от друга — можно вносить изменения в одну, и они не повлияют на другую (если вы явно этого не попросите). Работать вы начинаете в одной ветке — main, увидите чуть позже.

Форк (Fork) — собственное ответвление (fork) какого-то проекта. Это означает, что GitHub создаст вашу собственную копию проекта, данная копия будет находиться в вашем пространстве имён, и вы сможете легко делать изменения путём отправки (push) изменений.

Пул-реквест — pull request PR (пиар, он же merge request MR(мр)) — предложение изменения кода в чужом репозитории. Допустим, вы забрали к себе чужой репозиторий, поработали с ним и теперь хотите, чтобы ваши изменения попали в оригинальный репозиторий — тогда вы создаёте создаёте PR с просьбой добавить ваши изменения в репозиторий.

Начало работы

Начнём с простого — создадим свой репозиторий и сделаем наш первый коммит.

Картинка с сайта: habr.com

Картинка с сайта: habr.com

Зададим параметры:

• (1) Repository name: имя репозитория.

• (2) Description: описание репозитория.

• (3) Тип репозитория: Public (публичный) или Private (приватный). Сейчас выберем публичный — кто угодно может видеть содержимое репозитория.

• (4) Ставим галку на «Создать README файл». В этом файле в формате MarkDown описывают проект или прочую документацию. Именно содержимое этого файла можно увидеть, когда заходим на главную страницу репозитория. Примеры 1, 2, 3.

• (5) Если известно, на каком языке будет проект, можем добавить шаблон .gitignore для этого языка. Сейчас у нас нет какого-то языка, поэтому не будем создавать .gitignore.

• (6) Выбираем тип лицензии для нашего кода. В лицензии оговариваются права на проект. Стоит обратить внимание на BSD 3 или MIT, так как они предоставляют хороший баланс прав и ответственности.

(7) По умолчанию имя основной ветки в GitHub носит имя main, но до недавнего времени было master.

Картинка с сайта: habr.com

И нажимаем кнопку «Create repository». Успех, у нас есть первый репозиторий!

А что будет, если не добавим README и .gitignore?

На самом деле ничего страшного не произойдёт, но придётся выполнить ещё ряд шагов, чтобы проинициализировать git-репозиторий, прежде чем начать с ним работать.

Картинка с сайта: habr.com

Итак, мы создали репозиторий на удалённом сервере, теперь пора «забрать» его к себе на локальную машину и внести какие-то изменения.

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

Для начала получим путь до репозитория.

Картинка с сайта: habr.com

Теперь идём в консоль, переходим в директорию, где хотим хранить проекты, и выполним (git@github.com:ifireiceya/MyFirstRepo.git — путь, который мы скопировали ранее):

$ git clone git@github.com:ifireiceya/MyFirstRepo.git
Cloning into 'MyFirstRepo'...
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (4/4), done.

Переходим в новый каталог, где теперь лежит копия нашего проекта с GitHub:

$ cd MyFirstRepo

Можем посмотреть, что уже есть в этой директории:

$ ls -a
.git      LICENSE   README.md

Видим два знакомых файла,LICENSE и README.md, а также одну скрытую директорию .git.

В .git хранится метаинформация и вся история для проекта. На каждый проект есть только одна директория .git, и лежит она в корне проекта.

$ ls .git
HEAD                 # указатель на вашу активную ветку
config               # персональные настройки для проекта
description          # описание проекта
hooks                # pre/post action hooks
index                # индексный файл
logs                 # история веток проекта (где они располагались)        
objects              # ваши объекты (коммиты, теги и тд)
packed-refs refs     # указатели на ваши ветки разработки

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

При установке Git была добавлена утилита git config, которая позволяет просматривать и изменять большинство параметров работы Git’а. Если речь о данных пользователя или способе работы репозитория — git config будет самым удобным способом настройки.

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

Поэтому в терминале переходим в Git-репозиторий, для которого задаём настройки, и выполняем:

$ git config user.name "Дарья Меленцова"
$ git config user.email ifireice@example.com


# Если добавить опцию --global, то эти настройки запишутся в настройки пользователя и будут действовать для всех проектов. 
# Мы выполняем эту команду без параметра --global, чтобы настройки касались только вашего проекта.

Чтобы настраивать ещё больше параметров с помощью git config, прочитайте эту документацию.

Вносим изменения

Теперь нужно внести изменения в проект. Но перед этим посмотрим две полезных команды:

• git status — показывает текущее состояние файлов в репозитории (какие файлы изменились, удалились, добавились);

• git log — показывает историю изменений (это про зафиксированные изменения, то есть коммиты).

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

Вбиваем git status:

$ git status                                  
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

И видим, что у нас нет изменений. Говорят, «нет коммитов в репозитории». Конечно, мы успели только клонировать репозиторий и ещё ничего не делали.

Идём дальше и пробуем git log, который покажет, что в проекте был только один Initial commit — когда мы создавали репозиторий с README.md:

$ git log
commit 9ae1cbcc77f3b64d604612d4a599bdbb8b1cf204 (HEAD -> main, origin/main, origin/HEAD)
Author: ifireiceya <117034707+ifireiceya@users.noreply.github.com>
Date:   Mon Oct 31 00:01:05 2022 +0300

    Initial commit
(END)

Убедились, что у нас нет неучтённых изменений. Пора бы уже что-то сделать!

Открываем любимый текстовый редактор и создаём новый файл с именем hw.py.

Это будет небольшая программа на Python, которая при запуске печатает «Hello World!» (внезапно):

$ vi hw.py
print("Hello World!")

Отлично, код написан и даже хранится локально в нашем репозитории (мы же в директории проекта всё делали).

Теперь наша задача — сохранить изменения в «оригинальный» (удалённый) репозиторий. Для этого нужно:

1. Познакомить Git с новым файлом, то есть добавить файл в индекс — git add.

2. Зафиксировать (закоммитить) изменения — git commit.

3. Синхронизировать изменения с сервером — git push.

4. Посмотреть в репозиторий и убедиться, что всё сработало.

Делаем!

Картинка с сайта: habr.com

Появился файл hw.py, но он красный. Паника! Всё сломалось?!

Нет, всё идёт по плану, но прежде чем продолжить, стоит обсудить состояние файлов с точки зрения Git’а.

По мнению Git’а, файл может пребывать в одном из четырёх состояний:

1. Неотслеживаемый (untracked).

2. Изменённый (modified) — файл, в котором есть изменения, но он ещё не добавлен в коммит (не зафиксирован).

3. Отслеживаемый (staged) — файл, который добавили в индекс.

4. Зафиксированный (committed) — файл уже сохранён в локальной базе, и в нём не было изменений с последнего коммита.

Картинка с сайта: habr.com

В связке с состоянием файлов используют три основных секции проекта:

• Рабочая директория (working directory) — это директория, которая содержит в себе то, с чем вы работаете, или то, что вы извлекли из истории проекта в данный момент. Рабочая директория — это временное место, где вы можете модифицировать файлы, а затем выполнить коммит.

• Область индексирования (staging area) — индекс-файл в каталоге Git, который содержит информацию о том, что попадёт в следующий коммит.

• Каталог Git — место, где Git хранит метаданные и базу объектов вашего проекта. Помните ещё про .git?

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

Мы добавили новый файл hw.py и видим, что у него состояние untracked, то есть неважно, что мы делаем с файлом, Git проигнорирует любые изменения в нём.

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

Для этого используем команду git add <имя файла>.

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

$ git add hw.py
# если нужно добавить много файлов и не хочется описывать, можно использовать команду
# git add .
# но стоит точно понимать, что добавляем, иначе придётся потом удалять файлы из индекса
# кстати, для удаления используется команда git rm, но стоит почитать доку перед использованием

И ещё не забывайте о файле .gitignore, где перечислены папки и файлы репозитория, которые Git не должен отслеживать и синхронизировать их состояние (не добавлять их в индекс). Обычно в него добавляют файлы логов, результаты сборки и другое. Поддерживает шаблоны. Кстати, .gitignore — тоже файл, который надо добавить в индекс.

• Если файл попадает в правила.gitignore, то он не появится в git status.

• Если файл был добавлен в индекс, а потом добавлено правило для файла в .gitignore — файл всё равно будет отслеживаться и его надо явно удалить из индекса.

Посмотрим, как изменилось состояние нашего файла:

Картинка с сайта: habr.com

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

Для этого нужно закоммитить файл с помощью команды git commit.

При создании обычно лаконично описывают коммит, используя ключ -m:

$ git commit -m "add python hello world"     
[main 6d8a5c3] add python hello world
 1 file changed, 1 insertion(+)
 create mode 100644 hw.py

Пара слов о том, как писать сообщения для коммитов:

• максимум 50 символов;

• осознанно и понятно, как будто пишете для человека, который должен понять, что происходит внутри коммита;

• сообщение стоит начинать с заглавной буквы;

• если меняли код, пишите исходный код в сообщении.

$ git log

Картинка с сайта: habr.com

$ git push
Counting objects: 100% (4/4), done.
Delta compression using up to 12 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 341 bytes | 341.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:ifireiceya/MyFirstRepo.git
   9ae1cbc..6d8a5c3  main -> main

Предлагаем проверить, что наши изменения есть на GitHub. Идём в репозиторий и смотрим на него.

Картинка с сайта: habr.com

Задача немного посложнее

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

Например, есть у нас любимый опенсорсный проект, в который мы хотим принести добро и закрыть им какой-нибудь Issue.

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

Но будем делать это с позиции внешних пользователей в чужом репозитории.

Репозиторий хранится в ifireice/git, а изменения делает пользователь ifireiceya.

Пользователь ifireiceya не имеет доступа в ifireice/git, и ему придётся работать через Fork, то есть нужно сперва сделать копию этого репозитория к себе и вести разработку у себя, а потом отправить в основной репозиторий запрос на изменения — Pull Request.

Но обо всём по порядку. Сначала делаем Fork.

Картинка с сайта: habr.com

Откроется окно для создания нового форка (fork).

Изменится владелец репозитория (1), и опционально можно изменить описание проекта.

Картинка с сайта: habr.com

Картинка с сайта: habr.com

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

Теперь клонируем форк-репозиторий к себе на машинку и ведём разработку.

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

В нашем репозитории мы работали в ветке main и все изменения сохраняли в ней.

А теперь у нас большой проект, и над ним одновременно могут трудиться несколько разработчиков. Чтобы разные изменения не смешивались в кучу и чтобы один разработчик не мешал другому, разработка ведётся в разных независимых версиях продукта — ветках (branch). Когда работа закончена, все изменения сливаются в одну главную ветку.

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

$ git clone git@github.com:ifireiceya/git.git
$ cd git
# создадим новую ветку и сразу же переключимся на неё, чтобы работать там
$ git checkout -b fix-misprint
Switched to a new branch 'fix-misprint'

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

$ git branch
* fix-misprint
  main
# * помечена текущая активная ветка

На самом деле практика работать с ветками распространена не только при разработке в чужих репозиториях (collaborators), куда у вас нет доступа, но и в своих. Есть несколько стратегий выделения веток, но об этом не сейчас. Просто знайте, что есть ветки и с их помощью удобно вести разработку.

Можем посмотреть, что изменилось с последнего коммита, при помощи команды git diff (красным с “-” то, что было, зелёным с “+” — то, что стало):

$ git diff

Картинка с сайта: habr.com

$ git status
On branch fix-misprint
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")

$ git commit -am "Поправили опечатку"
[fix-misprint 188caa7] Поправили опечатку
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git push
fatal: The current branch fix-misprint has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin fix-misprint

Упс, fatal. Читаем подсказку от Git и выполняем:

$ git push --set-upstream origin fix-misprint
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 12 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 402 bytes | 402.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote:
remote: Create a pull request for 'fix-misprint' on GitHub by visiting:
remote:      https://github.com/ifireiceya/git/pull/new/fix-misprint
remote:
To github.com:ifireiceya/git.git
 * [new branch]      fix-misprint -> fix-misprint
Branch 'fix-misprint' set up to track remote branch 'fix-misprint' from 'origin'.

Успех!

Почему произошёл fatal: простой git push предполагает, что ветка, которую отслеживает текущая локальная ветвь, уже существует на удалённом сервере. У нас ветка новая и была создана только локально, поэтому нам нужно её создать, указав --set-upstream.

Проверим, что ветка появилась на GitHub.

Картинка с сайта: habr.com

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

Для этого создаём Pull request.

Картинка с сайта: habr.com

И увидим такую картину.

(1) репозиторий, в который хотим добавить изменения. — ifireice/git

(2) ветка, в которую хотим добавить изменения — main

(3) репозиторий, из которого хотим добавить изменения — ifireiceya/git

(4) ветка, из которой хотим добавить изменения — main

Картинка с сайта: habr.com

Картинка с сайта: habr.com

Картинка с сайта: habr.com

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

Будем считать, что у нас всё хорошо и наши изменения приняли без вопросов.

Как это выглядит на стороне ревьюверов:

Картинка с сайта: habr.com

Картинка с сайта: habr.com

Картинка с сайта: habr.com

Картинка с сайта: habr.com

Картинка с сайта: habr.com

На этом пока всё. Увидимся в следующих выпусках про Git и не только.

Что изучили

• Поговорили про системы контроля версий

• Настроили себе GitHub

• Создали первый репозиторий и внесли в него изменения

• Узнали про ветки, форки и остальное

• Сделали первый ПР

Что НЕ изучили

• Конфликты

• Откат изменений (reset, revert)

• Как забрать файл из другой ветки (Cherry-pick)

• rebase

Что ещё почитать

• Отличная книга Pro Git (есть на русском и английском)

• Курс «DevOps для эксплуатации и разработки»

• Trunk-Based Development — стратегия отведения веток

• GitFlow — другая стратегия отведения веток