Git полное руководство

В этой статье помимо архитектуры Git будут рассмотрены принципы работы таких команд, как add, checkout, reset, commit, merge, rebase, cherry-pick, pull, push и tag.

💡 Обо всем по порядку

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

Давайте сначала создадим новый проект с именем git-101, а затем инициализируем репозиторий git с помощью команды git init:

        $ mkdir git-101
$ cd git-101
    

Git CLI предоставляет два типа команд:

• Plumbing – состоит из низкоуровневых команд, используемых Git за кулисами, когда пользователи вводят высокоуровневые команды.
• Porcelain – которые являются высокоуровневыми командами, обычно используемыми пользователями Git.

В этом руководстве мы увидим, как команды plumbing связаны с командами porcelain, которые мы используем изо дня в день.

Внутри проекта, содержащего репозиторий Git, ознакомимся с компонентами Git:

        $ ls -F1 .git/

HEAD
config
description
hooks/
info/
objects/
refs/
    

Мы остановимся на основных:

• .git/objects/
• .git/refs
• HEAD

Разберем подробно каждый компонент.

💾 База данных объектов

Используя find, инструмент UNIX, мы можем ознакомиться со структурой папки .git/objects:

        $ find .git/objects

.git/objects
.git/objects/pack
.git/objects/info

    

В Git все хранится в структуре .git/objects, которая представляет собой Git Object Database.

Что мы можем сохранить в Git? Все.

🤔 Подождите!

Как это возможно?

С помощью хэш-функций.

🔵 Спасаемся хэшированием

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

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

SHA-1 – известная реализация хэш-функции, которая в целом безопасна и почти не имеет коллизий.

Возьмем, к примеру, хэширование строки my precious:

        $ echo -e "my precious" | openssl sha1
fa628c8eeaa9527cfb5ac39f43c3760fe4bf8bed

    

Примечание. Если вы работаете в Linux, вы можете использовать команду sha1sum вместо OpenSSL.

🔵 Сравнение различий в содержании

Хорошее хэширование – это безопасная практика, когда мы не можем знать необработанное значение, т. е. реверс-инжиниринг.

В случае если мы хотим знать, изменилось ли значение, мы просто помещаем значение в хэш-функцию и вуаля – мы можем сравнить разницу:

        $ echo -e "my precious" | openssl sha1
fa628c8eeaa9527cfb5ac39f43c3760fe4bf8bed

$ echo -e "no longer my precious" | openssl sha1
2e71c9ae2ef57194955feeaa99f8543ea4cd9f9f
    

Если хэши разные, то можно считать, что значение изменилось.

Можете ли вы найти здесь возможность? Как насчет использования SHA-1 для хранения данных и просто отслеживания всего путем сравнения хэшей? Это именно то, что Git делает внутри 🤯.

🔵 Git и SHA-1

Git использует SHA-1 для генерации хэширования всего и сохраняет его в .git/objectsпапке. Просто так!

hash-object, команда plumbing:

        $ echo "my precious" | git hash-object --stdin
8b73d29acc6ae79354c2b87ab791aecccf51701f
    

Сравним с OpenSSL версией:

        $ echo -e "my precious" | openssl sha1
fa628c8eeaa9527cfb5ac39f43c3760fe4bf8bed
    

Упс … это совсем другое. Это потому, что Git добавляет определенное слово, за которым следует размер содержимого и разделитель . Это слово Git называет типом объекта.

Да, у объектов Git есть типы. Первый объект, который мы рассмотрим, – это объект blob.

🔵 blob-объект

Когда мы отправляем, например, строку my precious в команду hash-object, Git добавляет паттерн {object_type} {content_size} к функции SHA-1, так что:

        blob 12myprecious

    

Затем:

        $ echo -e "blob 12my precious" | openssl sha1
8b73d29acc6ae79354c2b87ab791aecccf51701f

$ echo "my precious" | git hash-object --stdin
8b73d29acc6ae79354c2b87ab791aecccf51701f
    

Ура! 🎉

🔵 Хранение blob в базе данных

Но сама команда hash-object не сохраняется в папке .git/objects. Мы должны добавить -w и объект будет сохранен:

        $ echo "my precious" | git hash-object --stdin -w
8b73d29acc6ae79354c2b87ab791aecccf51701f

$ find .git/objects
...
.git/objects/8b
.git/objects/8b/73d29acc6ae79354c2b87ab791aecccf51701f

### Or, simply
$ find .git/objects -type f
.git/objects/8b/73d29acc6ae79354c2b87ab791aecccf51701f
    

Данное изображение и все последующие взяты отсюда.

🔵 Чтение необработанного содержимого блоба

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

🤔 Хорошо, но подождите.

Как Git узнает исходное значение?

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

cat-file, команда plumbing, при наличии ключа распаковывает сжатые данные, таким образом, получая исходное содержимое:

        $ git cat-file -p 8b73d29acc6ae79354c2b87ab791aecccf51701f
my precious
    

Таким образом, Git – это база данных с ключом и значением!

🔵 Как поделиться blob

Используя Git, мы хотим работать над содержимым и делиться им с другими людьми

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

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

1. Добавьте большой двоичный объект в промежуточную область
2. Сгруппируйте все blob-объекты в рабочей области в древовидную структуру
3. Добавьте метаданные в древовидную структуру (имя автора, дата, смысловое сообщение)

Давайте рассмотрим описанные выше шаги подробнее.

🔵 Stage area и index

update-index, команда plumbing, позволяет добавить blob в stage area и дать ему имя:

        $ git update-index 
    --add 
    --cacheinfo 100644 
    8b73d29acc6ae79354c2b87ab791aecccf51701f 
    index.txt
    

• --add: добавляет blob в stage, также называемый индексом.
• --cacheinfo: используется для регистрации файла, которого еще нет в рабочем каталоге
• хэш blob
• index.txt: имя большого двоичного объекта в индексе.

Где Git хранит индекс?

        $ cat .git/index

DIRCsҚjT¸zQp    index.txtÆ
                          7CJVVÙ
    

Недоступен для чтения человеком и сжат с использованием Zlib.

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

        $ git update-index {sha-1} f1.txt
$ git update-index {sha-1} f2.txt

    

После добавления blob-объектов в индекс мы можем сгруппировать их в древовидную структуру, чтобы мы могли поделиться ими.

🔵 Объект дерева

Команда write-tree (plumbing) позволяет Git группировать все blob, которые были добавлены в индекс, и создает в папке еще один объект: .git/objects

        $ git write-tree
3725c9e313e5ae764b2451a8f3b1415bf67cf471
    

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

        $ find .git/objects

### The new object
.git/objects/37
.git/objects/37/25c9e313e5ae764b2451a8f3b1415bf67cf471

### The blob previously created
.git/objects/8b
.git/objects/8b/73d29acc6ae79354c2b87ab791aecccf51701f
    

Давайте извлечем исходное значение с помощью cat-file для лучшего понимания:

        ### Using the option -t, we get the object type
$ git cat-file -t 3725c9e313e5ae764b2451a8f3b1415bf67cf471
tree

$ git cat-file -p 3725c9e313e5ae764b2451a8f3b1415bf67cf471
100644 blob 8b73d29acc6ae79354c2b87ab791aecccf51701f index.txt
    

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

В дереве объектов Git возвращает все объекты, которые были добавлены в индекс.

        100644 blob 8b73d29acc6ae79354c2b87ab791aecccf51701f index.txt

    

• 100644: кэш-информация
• blob: тип объекта
• хэш blob
• имя blob

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

🔵 Объект коммита

commit-tree, команда plumbing, получает дерево, сообщение коммита и создает еще один объект в папке .git/objects:

        $ git commit-tree 3725c -m 'my precious commit'
505555f4f07d90ae14a0f2e67cba7f7b9af539ee
    

Что это за объект?

        $ find .git/objects
...
.git/objects/50
.git/objects/50/5555f4f07d90ae14a0f2e67cba7f7b9af539ee

### cat-file
$ git cat-file -t 505555f4f07d90ae14a0f2e67cba7f7b9af539ee
commit
    

А как насчет его стоимости?

        $ git cat-file -p 505555f4f07d90ae14a0f2e67cba7f7b9af539ee

tree 3725c9e313e5ae764b2451a8f3b1415bf67cf471
author leandronsp <leandronsp@example.com> 1678768514 -0300
committer leandronsp <leandronsp@example.com> 1678768514 -0300

my precious commit

    

• tree 3725c: объект дерева ссылок
• автор/коммиттер
• сообщение коммита my precious commit

🤯 ОМГ! Я вижу здесь закономерность?

Кроме того, коммиты могут ссылаться на другие коммиты:

        $ git commit-tree 3725c -p 50555 -m 'second commit'
5ea578a41333bae71527db537072534a199a0b67
    

-p позволяет ссылаться на родительский коммит:

        $ git cat-file -p 5ea578a41333bae71527db537072534a199a0b67

tree 3725c9e313e5ae764b2451a8f3b1415bf67cf471
parent 505555f4f07d90ae14a0f2e67cba7f7b9af539ee
author leandronsp <leandronsp@gmail.com> 1678768968 -0300
committer leandronsp <leandronsp@gmail.com> 1678768968 -0300

second commit
    

Мы видим, что, благодаря коммиту с родителем, мы можем рекурсивно пройти все коммиты по всем их деревьям, пока не доберемся до финальных blob-объектов .

Возможное решение:

        $ git cat-file -p <first-commit-sha1>
$ git cat-file -p <first-commit-tree-sha1>
$ git cat-file -p <first-commit-parent-sha1>
$ git cat-file -p <parent-commit-sha1>
...
    

И так далее. Ну вы попали в точку.

🔵 Логирование для восстановления

git log, команда porcelain, решает эту проблему, просматривая все коммиты, их родителей и деревья, давая нам представление о временной хронологии нашей работы.

        $ git log 5ea57

commit 5ea578a41333bae71527db537072534a199a0b67
Author: leandronsp <leandronsp@gmail.com>
Date:   Mon Mar 13 22:42:48 2023 -0300

    second commit

commit 505555f4f07d90ae14a0f2e67cba7f7b9af539ee
Author: leandronsp <leandronsp@gmail.com>
Date:   Mon Mar 13 22:35:14 2023 -0300

    my precious commit
    

🤯 ОМГ!

Git – это гигантская, но легкая база данных графа ключ-значение!

🔵 Граф Git

В Git мы можем манипулировать указателями на граф.

• Blob – это моментальные снимки данных/файлов.
• Деревья представляют собой набор блобов или другое дерево.
• Коммиты ссылаются на деревья и/или другие коммиты, добавляя метаданные

Это очень мило и все такое, но использование sha1 в команде git log может быть громоздким.

Как насчет присвоения имен хэшам? Используйте ссылки.

Ссылки на Git

Ссылки находятся в папке .git/refs:

        $ find .git/refs

.git/refs/
.git/refs/heads
.git/refs/tags
    

🔵 Дадим имена коммитам

Мы можем связать любой хэш коммита с произвольным именем, расположенным в .git/refs/heads, например:

        echo 5ea578a41333bae71527db537072534a199a0b67 > .git/refs/heads/test

    

Теперь давайте выполним git log, используя новую ссылку:

        $ git log test

commit 5ea578a41333bae71527db537072534a199a0b67
Author: leandronsp <leandronsp@gmail.com>
Date:   Mon Mar 13 22:42:48 2023 -0300

    second commit

commit 505555f4f07d90ae14a0f2e67cba7f7b9af539ee
Author: leandronsp <leandronsp@gmail.com>
Date:   Mon Mar 13 22:35:14 2023 -0300

    my precious commit
    

Что еще лучше, Git предоставляет update-ref, команду plumbing, и мы можем использовать ее для обновления связи коммита со ссылкой:

        $ git update-ref refs/heads/test 5ea578a41333bae71527db537072534a199a0b67

    

Звучит знакомо, да? Да, речь идет о ветках.

🔵 Ветки

Ветки – это ссылки, указывающие на конкретный коммит.

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

На мгновение давайте подумаем о том, как git log работает без аргументов:

        $ git log

fatal: your current branch 'main' does not have any commits yet
    

🤔 Хм…

Как Git узнает, что моя текущая ветка является «основной»?

🔵 HEAD

Ссылка на HEAD находится в .git/HEAD. Это один файл, который указывает на главную ссылку (ветвь):

        $ cat .git/HEAD

ref: refs/heads/main
    

Точно так же, используя команду porcelain:

        $ git branch
* main
    

Используя symbolic-ref, команду plumbing, мы можем управлять тем, на какую ветку указывает HEAD:

        $ git symbolic-ref HEAD refs/heads/test

### Check the current branch
$ git branch
* test
    

Как и update-ref в ветках, мы можем обновить HEAD, используя symbolic-ref в любое время.

На картинке ниже мы изменим HEAD с ветки main на ветку fix:

Без аргументов команда git log обходит корневой коммит, на который ссылается текущая ветвь (HEAD):

        $ git log

commit 5ea578a41333bae71527db537072534a199a0b67 (HEAD -> test)
Author: leandronsp <leandronsp@gmail.com>
Date:   Tue Mar 14 01:42:48 2023 -0300

    second commit

commit 505555f4f07d90ae14a0f2e67cba7f7b9af539ee
Author: leandronsp <leandronsp@gmail.com>
Date:   Tue Mar 14 01:35:14 2023 -0300

    my precious commit
    

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

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

🍽️ Porcelain команды

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

Эти команды называются porcelain командами.

🔵 git add

Команда git add принимает файлы в рабочем каталоге в качестве аргументов, сохраняет их как blob-объекты в базе данных и добавляет их в индекс.

Короче говоря, git add:

1. запускает hash-object для каждого аргумента файла
2. запускает update-index для каждого аргумента файла

🔵 git commit

git commit принимает в качестве аргумента сообщение, группирует все ранее добавленные в индекс файлы и создает объект коммита.

Сначала выполняется write-tree:

Затем выполняется commit-tree:

        $ git commit -m 'another commit'

[test b77b454] another commit
 1 file changed, 1 deletion(-)
 delete mode 100644 index.txt

    

🕸️ Управление указателями в Git

Широко используются следующие команды porcelain, которые манипулируют ссылками Git под капотом.

Предполагая, что мы только что клонировали проект, в котором HEAD указывает на main ветку, которая указывает на коммит C1:

Как мы можем создать еще одну новую ветку из текущей HEAD и переместить HEAD в эту новую ветку?

🔵 git checkout

Используя git checkout с параметром -b, Git создаст новую ветку из текущей (HEAD) и переместит HEAD в эту новую ветку.

        ### HEAD
$ git branch
* main

### Creates a new branch "fix" using the same reference SHA-1
#### of the current HEAD
$ git checkout -b fix
Switched to a new branch 'fix'

### HEAD
$ git branch
* fix
main
    

Какая plumbing-команда отвечает за перемещение HEAD? Точно, symbolic-ref.

После этого мы делаем новую работу в ветке fix, а затем выполняем git commit, который добавит новый коммит под названием C3:

Запустив git checkout, мы можем продолжать переключать HEAD между разными ветвями:

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

Мы уже знаем, что это делает команда plumbing update-ref:

        $ git update-ref refs/heads/fix 356c2

    

🔵 git reset

Команда git reset (porcelain) запускает update-ref внутри, поэтому нам просто нужно выполнить:

        $ git reset 356c2

    

Но как Git узнает, какую ветку нужно переместить? Что ж, git reset перемещает ветку, на которую указывает HEAD.

Что делать, если есть различия между ревизиями? Используя reset, Git перемещает указатель, но оставляет все различия в рабочей области (индексе).

        $ git reset b77b

    

Проверка с помощью git status:

        $ git status

On branch fix
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        another.html
        bye.html
        hello.html

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

Коммит ревизии был изменен в ветке fix и все отличия перенесены в index .

Тем не менее, что нам делать, если мы хотим сбросить и отбросить все различия? Просто использовать параметр --hard:

При использовании git reset --hard любые различия между ревизиями будут отброшены, и они не будут отображаться в индексе .

💡 Золотой совет о перемещении ветки

Если мы хотим выполнить подключение update-ref к другой ветке, нет необходимости проверять ветку, как это необходимо в git reset.

Вместо этого мы можем выполнить porcelain-команду git branch -f source target:

        $ git branch -f main b77b

    

Под капотом он выполняет git reset --hard в исходной ветке. Давайте проверим, на какой коммит указывает основная ветка:

        $ git log main --pretty=oneline -n1
b77b454a9a507f839880879a895ac4f241177a28 (main) another commit
    

Также мы подтверждаем, что ветка fix по-прежнему указывает на коммит 369cd:

        $ git log fix --pretty=oneline -n1
369cd96b1f1ef6fa7de1ff2ed12e15be979dcffa (HEAD -> fix, test) add files

    

Мы сделали git reset без перемещения HEAD!

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

🔵 git cherry-pick

С помощью porcelain-команды git cherry-pick мы можем применить произвольную фиксацию к текущей ветке.

Возьмем следующий сценарий:

• main-пункты к C3 – C2 – C1
• fix для точек на C5 – C4 – C2 – C1
• HEAD указывает на fix

В ветке исправления отсутствует фиксация C3, на которую ссылается основная ветка.

Для этого запустим git cherry-pick C3:

Обратите внимание, что:

• коммит C3 будет клонирован в новый коммит с именем C3
• этот новый коммит будет ссылаться на коммит C5
• fix переместит указатель на C3′
• HEAD продолжает указывать на исправление

После применения изменений график будет представлен следующим образом:

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

Вы не ошиблись, здесь мы говорим о git merge.

🔵 git merge

Опишем следующий сценарий:

• Main-пункты к C3 – C2 – C1
• Fix точек на C4 – C3 – C2 – C1
• HEAD указывает на main

Мы хотим применить исправленную ветку к текущей (основной) ветке, т. е. выполнить git merge fix.

Обратите внимание, что ветка fix содержит все коммиты, принадлежащие основной ветке (C3 – C2 – C1), имея только один коммит перед основным (C4).

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

Такое слияние называется fast-forward, как показано на изображении ниже:

Когда fast-forward невозможен

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

Когда в ветке слияния – ветке исправления в приведенном выше примере – отсутствует одна или несколько коммитов из текущей ветки (основной): коммит C3.

Таким образом, fast-forward невозможен.

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

Во-первых, Git ищет следующего общего родителя двух ветвей, в этом примере коммит C2.

Во-вторых, Git делает снимок целевой ветки фиксации C3:

В-третьих, Git делает снимок исходной ветки фиксации C5:

Наконец, Git автоматически создает слияние фиксации (C6) и указывает на двух родителей соответственно: C3 (цель) и C5 (источник):

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

Не заблуждайтесь, этот процесс слияния называется трехсторонним слиянием!

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

Да, это git rebase.

🔵 git rebase

Рассмотрим следующее изображение:

• Main-пункты к C3 – C2 – C1
• fix точек на C5 – C4 – C2 – C1
• HEAD указывает на fix

Мы хотим перебазировать основную ветку в ветку исправления, посредством git rebase main. Но как работает git rebase?

👉git reset

Сначала Git выполняет git reset main, при этом ветка fix будет указывать на тот же указатель основной ветки: C3 – C2 – C1.

На данный момент у коммитов C5-C4 нет ссылок.

👉git cherry-pick

Во-вторых, Git выполняет git cherry-pick C5 в текущую ветку:

Обратите внимание, что выбранные коммиты клонируются, поэтому окончательный хэш изменится: C5 – C4 станет C5′ – C4′.

После у нас может быть следующий сценарий:

👉git reset еще раз

Наконец, Git выполнит git reset C5', поэтому указатель ветки fix переместится с C3 на C5'.

Процесс rebase завершен.

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

🌐 Удаленные ветки

Чтобы работать с удаленными ветками, нам нужно добавить удаленную ветку в наш локальный репозиторий с помощью команды porcelain – git remote.

        $ git remote add origin git@github.com/myaccount/myrepo.git

    

Удаленные репозитории находятся в папке .git/refs/remotes:

        $ find .git/refs
...
.git/refs/remotes/origin
.git/refs/remotes/origin/main
    

🔵 Скачать с удаленного репозитория

Как нам синхронизировать удаленную ветку с нашей локальной веткой?

Git предлагает два шага:

👉git fetch

С помощью git fetch origin main Git загрузит удаленную ветку и синхронизирует ее с новой локальной веткой с именем origin/main, также известной как upstream branch (восходящая ветка).

👉git merge

После извлечения и синхронизации вышестоящей ветки мы можем выполнить git merge origin/main и, поскольку восходящая ветка опережает нашу локальную ветку, Git безопасно применит ускоренное слияние.

Однако комбинация fetch + merge может повториться, так как мы будем синхронизировать локальные/удаленные ветки несколько раз в день.

Но сегодня наш счастливый день, и Git предоставляет команду git pullchina, которая выполняет fetch + merge от нашего имени.

👉git pull

git pull выполнит выборку (синхронизирует удаленную ветвь с вышестоящей ветвью), а затем объединит восходящую ветвь с локальной ветвью.

Итак, мы увидели, как получать/загружать изменения с репозитория. С другой стороны, как насчет отправки локальных изменений на удаленные?

🔵 Загрузить на удаленный репозиторий

Git предоставляет porcelain команду под названием git push:

👉git push

Выполнение git push origin main приведет к загрузке изменения на удаленный репозиторий:

Затем Git объединит восходящую ветвь origin/main с локальной main-веткой:

В конце мы получим следующее изображение:

Где:

• Удаленный репозиторий обновлен (локальные изменения отправлены)
• main к C4
• origin/main к C4
• HEAD указывает на main

🔵 Предоставление неизменяемых имен коммитам

Мы знаем, что ветки – это просто изменяемые ссылки на коммиты, поэтому мы можем переместить указатель ветки.

Однако Git также предлагает способ предоставления неизменяемых ссылок, указатели которых не могут быть изменены (если только вы не удалите их и не создадите снова).

Неизменяемые ссылки полезны, например, когда мы хотим пометить/отметить коммиты, которые готовы для какого-то производственного выпуска.

Да, мы говорим о тегах.

👉git tag

Используя команду (porcelain) git tag, мы можем давать имена коммитам, но мы не можем выполнить сброс или любую другую команду, которая изменила бы указатель.

Это очень полезно для управления версиями. Теги находятся в папке .git/refs/tags:

        $ find .git/refs

...
.git/refs/tags
.git/refs/tags/v1.0
    

Если мы хотим изменить указатель тега, мы должны удалить его и создать еще один с тем же именем.

💡 Git reflog

И последнее, но не менее важное – вызываемая команда git reflog, которая сохраняет все изменения, которые мы сделали, в нашем локальном репозитории.

        $ git reflog

369cd96 (HEAD -> fix, test) HEAD@{0}: reset: moving to main
b77b454 (main) HEAD@{1}: reset: moving to b77b
369cd96 (HEAD -> fix, test) HEAD@{2}: checkout: moving from main to fix
369cd96 (HEAD -> fix, test) HEAD@{3}: checkout: moving from fix to main
369cd96 (HEAD -> fix, test) HEAD@{4}: checkout: moving from main to fix
369cd96 (HEAD -> fix, test) HEAD@{5}: checkout: moving from fix to main
369cd96 (HEAD -> fix, test) HEAD@{6}: checkout: moving from main to fix
369cd96 (HEAD -> fix, test) HEAD@{7}: checkout: moving from test to main
369cd96 (HEAD -> fix, test) HEAD@{8}: checkout: moving from main to test
369cd96 (HEAD -> fix, test) HEAD@{9}: checkout: moving from test to main
369cd96 (HEAD -> fix, test) HEAD@{10}: commit: add files
b77b454 (main) HEAD@{11}: commit: another commit
5ea578a HEAD@{12}:
    

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

Подведение итогов

Какое долгое путешествие!

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

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

***

Материалы по теме

• Git за полчаса: руководство для начинающих
• 📁 Настраиваем Git для правильной работы с опенсорс-проектами
• Основы Git: контроль версий для самых маленьких
• 💽 Git для Data Science: контроль версий моделей и датасетов с помощью DVC
• 👍 Как правильно писать сообщения коммитов в GIT, чтобы всем было хорошо

Highlights of the article:  

1. Introduction to Git
2. Git Repository Structure
3. Github
4. Accessing Github central repository via HTTPS or ssh
5. Working with git – Important Git commands

Introduction to Git

For installation purposes on ubuntu, you can refer to this article: How to Install, Configure and Use GIT on Ubuntu? 

Git is a distributed version control system. So, What is a Version Control System? 

A version Control system is a system that maintains different versions of your project when we work in a team or as an individual. (system managing changes to files) As the project progresses, new features get added to it. So, a version control system maintains all the different versions of your project for you and you can roll back to any version you want without causing any trouble to you for maintaining different versions by giving names to it like MyProject, MyProjectWithFeature1, etc. 

Distributed Version control system means every collaborator(any developer working on a team project)has a local repository of the project in his/her local machine unlike central where team members should have an internet connection to every time update their work to the main central repository. 

So, by distributed we mean: the project is distributed. A repository is an area that keeps all your project files, images, etc. In terms of Github: different versions of projects correspond to commits. 
For more details on introduction to Github, you can refer: Introduction to Github 

Git Repository Structure

It consists of 4 parts:  

1. Working directory: This is your local directory where you make the project (write code) and make changes to it.
2. Staging Area (or index): this is an area where you first need to put your project before committing. This is used for code review by other team members.
3. Local Repository: this is your local repository where you commit changes to the project before pushing them to the central repository on Github. This is what is provided by the distributed version control system. This corresponds to the .git folder in our directory.
4. Central Repository: This is the main project on the central server, a copy of which is with every team member as a local repository.

All the repository structure is internal to Git and is transparent to the developer. 

Some commands which relate to repository structure:  

// transfers your project from working directory
// to staging area.
git add .

// transfers your project from staging area to 
// Local Repository.
git commit -m "your message here"


// transfers project from local to central repository.
// (requires internet)
git push

Github

Github basically is a for-profit company owned by Microsoft, which hosts Git repositories online. It helps users share their git repository online, with other users, or access it remotely. You can also host a public repository for free on Github. 

User share their repository online for various reasons including but not limited to project deployment, project sharing, open source contribution, helping out the community and many such.

Accessing Github central repository via HTTPS or SSH

Here, transfer project means transfer changes as git is very lightweight and works on changes in a project. It internally does the transfer by using Lossless Compression Techniques and transferring compressed files. Https is the default way to access Github central repository.  

• By git remote add origin http_url: remote means the remote central repository. Origin corresponds to your central repository which you need to define (hereby giving HTTPS URL) in order to push changes to Github.
• Via SSH: connect to Linux or other servers remotely.

If you access Github by ssh you don’t need to type your username and password every time you push changes to GitHub. 

Terminal commands: 

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
This does the ssh key generation using RSA cryptographic algorithm.

eval "$(ssh-agent -s)" -> enable information about local login session.

ssh-add ~/.ssh/id_rsa -> add to ssh key.
cat ~/.ssh/id_rsa (use .pub file if not able to connect)
add this ssh key to github.


Now, go to github settings -> new ssh key -> create key

ssh -T git@github.com -> activate ssh key (test connection)

Refresh your github Page.

Working with git – Important Git commands 

Git user configuration (First Step)  

git --version (to check git version)
git config --global user.name "your name here"
git config --global user.email "your email here"

These are the information attached to commits.  

Initialize directory 

git init 

initializes your directory to work with git and makes a local repository. .git folder is made (OR) 

git clone http_url 

This is done if we have an existing git repository and we want to copy its content to a new place.

Connecting to the remote repository 

git remote add origin http_url/ssh_url 

connect to the central repo to push/pull. pull means adopting the changes on the remote repository to your local repository. push merges the changes from your local repository to the remote repository.  

git pull origin master

One should always first pull contents from the central repo before pushing so that you are updated with other team members’ work. It helps prevent merge conflicts. Here, master means the master branch (in Git).  

Stash Area in git

git stash

Whichever files are present in the staging area, it will move that files to stash before committing it. 

git stash pop

Whenever we want files for commit from stash we should use this command.

git stash clear

By doing this, all files from stash area is been deleted.

Steps to add a file to a remote Repository: 

First, your file is in your working directory, Move it to the staging area by typing:  

git add -A (for all files and folders)
#To add all files only in the current directory
git add .

git status: here, untracked files mean files that you haven’t added to the staging area. Changes are not staged for commit means you have staged the file earlier than you have made changes in that files in your working directory and the changes need to be staged once more. Changes ready to be committed: these are files that have been committed and are ready to be pushed to the central repository.  

git status

git commit -a -m "message for commit"
-a: commit all files and for files that have been 
     staged earlier need not to be git add once more
-a option does that automatically.

git push origin master -> pushes your files to 
                         github master branch
git push origin anyOtherBranch -> pushes any 
                      other branch to github.
git log ; to see all your commits

git checkout commitObject(first 8 bits) file.txt-> 
revert back to this previous commit for file file.txt

Previous commits might be seen through the git log command. 

HEAD -> pointer to our latest commit.  

Ignoring files while committing

In many cases, the project creates a lot of logs and other irrelevant files which are to be ignored. So to ignore those files, we have to put their names in“.gitignore” file.  

touch .gitignore
echo "filename.ext" >>.gitignore
#to ignore all files with .log extension
echo "*.log" > .gitignore

Now the filenames written in the .gitignore file would be ignored while pushing a new commit. To get the changes between commits, commit, and working tree. 

git diff

The ‘git diff’ command compares the staging area with the working directory and tells us the changes made. It compares the earlier information as well as the current modified information. 

Branching in Git 

create branch ->
git branch myBranch
or
git checkout -b myBranch -> make and switch to the 
                                  branch myBranch

Do the work in your branch. Then, 

git checkout master ; to switch back to master branch

Now,  merge contents with your myBranch By: 

git merge myBranch (writing in master branch)

This merger makes a new commit. 

Another way 

git rebase myBranch

This merges the branch with the master in a serial fashion. Now,  

git push origin master

To remove  or delete a file 

To remove.  a file from the  Git repository we use 

git rm “file name”

To remove only from the staging area 

git rm –cached “ file name”

Undoing change

To change all the  files to as same as the previous commit then use

git checkout -f

Contributing to Open Source

Open Source might be considered as a way where user across the globe may share their opinions, customizations or work together to solve an issue or to complete the desired project together. Many companies host there repositories online on Github to allow access to developers to make changes to their product. Some companies(not necessarily all) rewards their contributors in different ways.

You can contribute to any open source project on Github by forking it, making desired changes to the forked repository, and then opening a pull request. The project owner will review your project and will ask to improve it or will merge it. 

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

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

Оглавление

Предисловие
1. Настройка git
….1.1 Конфигурационные файлы
….1.2 Настройки по умолчанию
….1.3 Псевдонимы (aliases)
2. Основы git
….2.1 Создание репозитория
….2.2 Состояние файлов
….2.3 Работа с индексом
….2.4 Работа с коммитами
….2.5 Просмотр истории
….2.6 Работа с удалённым репозиторием
3. Ветвление в git
….3.1 Базовые операций
….3.2 Слияние веток
….3.3 Rerere
4. Указатели в git
….4.1 Перемещение указателей
5. Рекомендуемая литература

Предисловие

Git — самая популярная распределённая система контроля версиями.[1][2]

Основное предназначение Git – это сохранение снимков последовательно улучшающихся состояний вашего проекта (Pro git, 2019).

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

Здесь рассматриваются только технические аспекты git’а, для более подробного погружения в философию git’а и его внутреннюю реализацию, советую прочитать несколько полезных книг (см. Рекомендуемая литература).

1. Настройка git

Прежде чем начинать работу с git необходимо его настроить под себя!

1.1 Конфигурационные файлы

• /etc/gitconfig — Общие настройки для всех пользователей и репозиториев
• ~/.gitconfig или ~/.config/git/config — Настройки конкретного пользователя
• .git/config — Настройки для конкретного репозитория

Есть специальная команда

git config [<опции>]

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

В зависимости какой параметр вы передадите команде git config (—system, —global, —local), настройки будут записываются в один из этих файлов. Каждый из этих “уровней” (системный, глобальный, локальный) переопределяет значения предыдущего уровня!

Что бы посмотреть в каком файле, какие настройки установлены используйте git config —list —show-origin.

Игнорирование файлов
В git вы сами решаете какие файлы и в какой коммит попадут, но возможно вы бы хотели, что бы определённые файлы никогда не попали в индекс и в коммит, да и вообще не отображались в списке не отлеживаемых. Для этого вы можете создать специальный файл (.gitignore) в вашем репозитории и записать туда шаблон игнорируемых файлов. Если вы не хотите создавать такой файл в каждом репозитории вы можете определить его глобально с помощью core.excludesfile (см. Полезные настройки). Вы также можете скачать готовый .gitignore file для языка программирования на котором вы работаете.
Для настройки .gitignore используйте регулярные выражения bash.

1.2 Настройки по умолчанию

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

Используйте

git config name value

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

git config --global core.editor nano

установит редактор по умолчанию nano.

Вы можете посмотреть значение существующего параметра с помощью git config —get [name] где name это параметр, значение которого вы хотите получить.

Полезные настройки:

• user.name — Имя, которое будет использоваться при создании коммита
• user.email — Email, который будет использоваться при создании коммита
• core.excludesfile — Файл, шаблон которого будет использоваться для игнорирования определённых файлов глобально
• core.editor — Редактор по умолчанию
• commit.template — Файл, содержимое которого будет использоваться для сообщения коммита по умолчанию (См. Работа с коммитами).
• help.autocorrect — При установке значения 1, git будет выполнять неправильно написанные команды.
• credential.helper [mode] — Устанавливает режим хранения учётных данных. [cache] — учётные данные сохраняются на определённый период, пароли не сохраняются (—timeout [seconds] количество секунд после которого данные удаляются, по умолчанию 15 мин). [store] — учётные данные сохраняются на неограниченное время в открытом виде (—file [file] указывает путь для хранения данных, по умолчанию ~/.git-credentials).

1.3 Псевдонимы (aliases)

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

git config alias.SHORT_NAME COMMAND

где SHORT_NAME это имя для сокращения, а COMMAND команда(ы) которую нужно сократить. Пример:

git config --global alias.last 'log -1 HEAD'

после выполнения этой команды вы можете просматривать информацию о последнем коммите на текущей ветке выполнив git last.

Я советую вам использовать следующие сокращения (вы также можете определить любые свои):

• st = status
• ch = checkout
• br = branch
• mg = merge
• cm = commit
• reb = rebase
• lg = «git log —pretty=format:’%h — %ar: %s’»

Для просмотра настроек конфигурации используйте: git config —list.

2. Основы git

Здесь перечислены только обязательные и полезные (на мой взгляд) параметры, ибо перечисление всех неуместно. Для этого используйте git command -help или —help, где command — название команды справку о который вы хотите получить.

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

• git init [<опции>] — Создаёт git репозитории и директорию .git в текущей директории (или в директории указанной после —separate-git-dir <каталог-git>, в этом случае директория .git будет находится в другом месте);
• git clone [<опции>] [—] <репозиторий> [<каталог>] [-o, —origin <имя>] [-b, —branch <ветка>] [—single-branch] [—no-tags] [—separate-git-dir <каталог-git>] [-c, —config <ключ=значение>] — Клонирует репозитории с названием origin (или с тем которое вы укажите -o <имя>), находясь на той ветке, на которую указывает HEAD (или на той которую вы укажите -b <ветка>). Также вы можете клонировать только необходимую ветку HEAD (или ту которую укажите в -b <ветка>) указав —single-branch. По умолчанию клонируются все метки, но указав —no-tags вы можете не клонировать их. После выполнения команды создаётся директория .git в текущей директории (или в директории указанной после —separate-git-dir <каталог-git>, в этом случае директория .git будет находится в другом месте);

2.2 Состояние файлов

Для просмотра состояния файлов в вашем репозитории используйте:

git status [<опции>]

Эта команда может показать вам: на какой ветке вы сейчас находитесь и состояние всех файлов. Обязательных опций нет, из полезных можно выделить разве что -s которая покажет краткое представление о состояний файлов.

Жизненный цикл файлов
Как видно на картинке файлы могут быть не отслеживаемые (Untracked) и отслеживаемые. Отслеживаемые файлы могут находится в 3 состояниях: Не изменено (Unmodified), изменено (Modified), подготовленное (Staged).
Если вы добавляете (с помощью git add) «Не отслеживаемый» файл, то он переходит в состояние «Подготовлено».
Если вы изменяете файл в состояния «Не изменено», то он переходит в состояние «Изменено». Если вы сохраняете изменённый файл (то есть находящийся в состоянии «Изменено») он переходит в состояние «Подготовлено». Если вы делаете коммит файла (то есть находящийся в состоянии «Подготовлено») он переходит в состояние «Не изменено».
Если версии файла в HEAD и рабочей директории отличаются, то файл будет находится в состояний «Изменено», иначе (если версия в HEAD и в рабочем каталоге одинакова») файл будет находится в состояний «Не изменено».
Если версия файла в HEAD отличается от рабочего каталога, но не отличается от версии в индексе, то файл будет в состоянии «Подготовлено».

Этот цикл можно представить следующим образом:
Unmodified -> Modified -> Staged -> Unmodified
То есть вы изменяете файл сохраняете его в индексе и делаете коммит и потом все сначала.

2.3 Работа с индексом

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

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

Что бы просмотреть индекс, используйте git status.

Что бы добавить файлы в индекс используйте

git add [<опции>]

Полезные параметры команды git add:

• -f, —force — добавить также игнорируемые файлы
• -u, —update — обновить отслеживаемые файлы

Что бы удалить файлы из индекса вы можете использовать 2 команды git reset и git restore.
git-restore — восстановит файлы рабочего дерева.
git-reset — сбрасывает текущий HEAD до указанного состояния.
По сути вы можете добиться одного и того же с помощью обеих команд.

Что бы удалить из индекса некоторые файлы используйте:

git restore --staged <file>

таким образом вы восстановите ваш индекс (или точнее удалите конкретные файлы из индекса), будто бы git add после последнего коммита не выполнялся для них. С помощью этой команды вы можете восстановить и рабочую директорию, что бы она выглядела так, будто бы после коммита не выполнялось никаких изменений. Вот только эта команда имеет немного странное поведение — если вы добавили в индекс новую версию вашего файла вы не можете изменить вашу рабочую директорию, пока индекс отличается от HEAD. Поэтому вам сначала нужно восстановить ваш индекс и только потом рабочую директорию. К сожалению сделать это одной командой не возможно так как при передаче обеих аргументов (git restore -SW) не происходит ничего. И точно также при передаче -W тоже ничего не произойдет если файл в индексе и HEAD разный. Наверное, это сделали для защиты что бы вы случайно не изменили вашу рабочую директорию. Но в таком случае почему аргумент -W передаётся по умолчанию? В общем мне не понятно зачем было так сделано и для чего вообще была добавлена эта команда. По мне так reset справляется с этой задачей намного лучше, да и еще и имеет более богатый функционал так как может перемещать индекс и рабочую директорию не только на последний коммит но и на любой другой.

Но собственно разработчики рекомендуют для сброса индекса использовать именно git restore -S . Вместо git reset HEAD .

С помощью git status вы можете посмотреть какие файлы изменились но если вы также хотите узнать что именно изменилось в файлах то воспользуйтесь командой:

git diff [<options>]

таким образом выполнив команду без аргументов вы можете сравнить ваш индекс с рабочей директорией. Если вы уже добавил в индекс файлы, то используйте git diff —cached что бы посмотреть различия между последним коммитом (или тем который вы укажите) и рабочей директории. Вы также можете посмотреть различия между двумя коммитами или ветками передав их как аргумент. Пример: git diff 00656c 3d5119 покажет различия между коммитом 00656c и 3d5119.

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

Теперь, когда ваш индекс находится в нужном состояний, пора сделать коммит ваших изменений. Запомните, что все файлы для которых вы не выполнили git add после момента редактирования — не войдут в этот коммит. На деле файлы в нём будут, но только их старая версия (если таковая имеется).

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

git commit [<опции>]

Полезные опции команды git commit:

• -F, —file [file] — Записать сообщение коммита из указанного файла
• —author [author] — Подменить автора коммита
• —date [date] — Подменить дату коммита
• -m, —mesage [message] — Сообщение коммита
• -a, —all — Закоммитеть все изменения в файлах
• -i, —include [files…] — Добавить в индекс указанные файлы для следующего коммита
• -o, —only [files…] — Закоммитеть только указанные файлы
• —amend — Перезаписать предыдущий коммит

Вы можете определить сообщение для коммита по умолчанию с помощью commit.template. Эта директива в конфигурационном файле отвечает за файл содержимое которого будет использоваться для коммита по умолчанию. Пример: git config —global commit.template ~/.gitmessage.txt.

Вы также можете изменить, удалить, объединить любой коммит.
Как вы уже могли заметить вы можете быстро перезаписать последний коммит с помощью git commit —amend.
Для изменения коммитом в вашей истории используйте

git rebase -i <commit>

где commit это верхний коммит в вашей цепочке с которого вы бы хотели что либо изменить.

После выполнения git rebase -i в интерактивном меню выберите что вы хотите сделать.

• pick <коммит> = использовать коммит
• reword <коммит> = использовать коммит, но изменить сообщение коммита
• edit <коммит> = использовать коммит, но остановиться для исправления
• squash <коммит> = использовать коммит, но объединить с предыдущим коммитом
• fixup <коммит> = как «squash», но пропустить сообщение коммита
• exec <команда> = выполнить команду (остаток строки) с помощью командной оболочки
• break = остановиться здесь (продолжить с помощью «git rebase —continue»)
• drop <коммит> = удалить коммит
• label <метка> = дать имя текущему HEAD
• reset <метка> = сбросить HEAD к указанной метке

Для изменения сообщения определённого коммита.
Необходимо изменить pick на edit над коммитом который вы хотите изменить.
Пример: вы хотите изменить сообщение коммита 750f5ae.

pick 2748cb4 first commit
edit 750f5ae second commit
pick 716eb99 third commit

После сохранения скрипта вы вернётесь в командную строку и git скажет что необходимо делать дальше:

Остановлено на 750f5ae … second commit
You can amend the commit now, with

git commit —amend

Once you are satisfied with your changes, run

git rebase —continue

Как указанно выше необходимо выполнить git commit —amend для того что бы изменить сообщение коммита. После чего выполнить git rebase —continue. Если вы выбрали несколько коммитов для изменения названия то данные операций необходимо будет проделать над каждым коммитом.

Для удаления коммита
Необходимо удалить строку с коммитом.
Пример: вы хотите удалить коммит 750f5ae
Нужно изменить скрипт с такого:
pick 2748cb4 third commit
pick 750f5ae second commit
pick 716eb99 first commit
на такой:
pick 2748cb4 first commit
pick 716eb99 third commit

Для объединения коммитов
Необходимо изменить pick на squash над коммитами которые вы хотите объединить.
Пример: вы хотите объединить коммиты 750f5ae и 716eb99.
Необходимо изменить скрипт с такого:
pick 2748cb4 third commit
pick 750f5ae second commit
pick 716eb99 first commit
На такой
pick 2748cb4 third commit
squash 750f5ae second commit
squash 716eb99 first commit

Заметьте что в интерактивном скрипте коммиты изображены в обратном порядке нежели в git log. С помощью squash вы объедините коммит 750f5ae с 716eb99, а 750f5ae с 2748cb4. В итоге получая один коммит содержащий изменения всех трёх.

2.5 Просмотр истории

С помощью команды

git log [<опции>] [<диапазон-редакций>]

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

Полезные параметры команды git log:

• -p — Показывает разницу для каждого коммита.
• —stat — Показывает статистику измененных файлов для каждого коммита.
• —graph — Отображает ASCII граф с ветвлениями и историей слияний.

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

• -(n) Показывает только последние n коммитов.
• —since, —after — Показывает коммиты, сделанные после указанной даты.
• —until, —before — Показывает коммиты, сделанные до указанной даты.
• —author — Показывает только те коммиты, в которых запись author совпадает с указанной строкой.
• —committer — Показывает только те коммиты, в которых запись committer совпадает с указанной строкой.
• —grep — Показывает только коммиты, сообщение которых содержит указанную строку.
• -S — Показывает только коммиты, в которых изменение в коде повлекло за собой добавление или удаление указанной строки.

Вот несколько примеров:
git log —since=3.weeks — Покажет коммиты за последние 2 недели
git log —since=«2019-01-14» — Покажет коммиты сделанные 2019-01-14
git log —since=«2 years 1 day ago» — Покажет коммиты сделанные 2 года и один день назад.

Также вы можете настроить свои формат вывода коммитов с помощью

git log --format:["format"]

Варианты форматирования для git log —format.

• %H — Хеш коммита
• %h — Сокращенный хеш коммита
• %T — Хеш дерева
• %t — Сокращенный хеш дерева
• %P — Хеш родителей
• %p — Сокращенный хеш родителей
• %an — Имя автора — %ae — Электронная почта автора
• %ad — Дата автора (формат даты можно задать опцией —date=option)
• %ar — Относительная дата автора
• %cn — Имя коммитера
• %ce — Электронная почта коммитера
• %cd — Дата коммитера
• %cr — Относительная дата коммитера
• %s — Содержание

Пример:

git log --pretty=format:"%h - %ar : %s"

покажет список коммитов состоящий из хэша времени и сообщения коммита.

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

Так как git это распределённая СКВ вы можете работать не только с локальными но и с внешними репозиториеми.

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

Для работы с внешними репозиториями используйте:

git remote [<options>]

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

git remote add [<options>] <name> <adres>

Вы можете тут же извлечь внешние ветки с помощью -f, —fetch (вы получите имена и состояние веток внешнего репозитория). Вы можете настроить репозитории только на отправку или получение данных с помощью —mirror[=(push|fetch)]. Для получения меток укажите —tags.

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

Для отслеживания веток используйте git branch -u <rep/br> где rep это название репозитория, br название внешней ветки, а branch название локальной ветки. Либо git branch —set-upstream local_br origin/br для того что бы указать какая именно локальная ветка будет отслеживать внешнюю ветку.

Когда ваша ветка отслеживает внешнюю вы можете узнать какая ветка (локальная или внешняя) отстаёт или опережает и на сколько коммитов. К примеру если после коммита вы не выполняли git push то ваша ветка будет опережать внешнюю на 1 коммит. Вы можете узнать об этом выполнив git branch -vv, но прежде выполните git fetch [remote-name] (—all для получения обновления со всех репозиториев) что бы получить актуальные данные из внешнего репозитория. Для отмены отслеживания ветки используйте git branch —unset-upstream [<local_branch>].

Для загрузки данных с внешнего репозитория используйте git pull [rep] [branch]. Если ваши ветки отслеживают внешние, то можете не указывать их при выполнение git pull. По умолчанию вы получите данные со всех отслеживаемых веток.

Для загрузки веток на новую ветку используйте git checkout -b <new_branch_name> <rep/branch>.

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

git push [<rep>] [<br>]

где rep это название внешнего репозитория, а br локальная ветка которую вы хотите отправить. Также вы можете использовать такую запись git push origin master:dev. Таким образом вы выгрузите вашу локальную ветку master на origin (но там она будет называется dev). Вы не сможете отправить данные во внешний репозитории если у вас нет на это прав. Также вы не сможете отправить данные на внешнюю ветку если она опережает вашу (в общем то отправить вы можете используя -f, —forse в этом случае вы перепишите историю на внешнем репозитории). Вы можете не указывать название ветки если ваша ветка отслеживает внешнюю.

Для удаления внешних веток используйте

git push origin --delete branch_name

Для получения подробной информации о внешнем репозитории (адреса для отправки и получения, на что указывает HEAD, внешние ветки, локальные ветки настроенные для git pull и локальные ссылки настроенные для git push)

git remote show <remote_name>

Для переименования названия внешнего репозитория используйте

git remote rename <last_name> <new_name>

Для удаления ссылки на внешний репозитории используйте

git remote rm <name>

3. Ветвление в git

Ветвление это мощные инструмент и одна из главных фич git’а поскольку позволяет вам быстро создавать и переключатся между различным ветками вашего репозитория. Главная концепция ветвления состоит в том что вы можете откланяться от основной линии разработки и продолжать работу независимо от нее, не вмешиваясь в основную линию. Ветка всегда указывает на последний коммит в ней, а HEAD указывает на текущую ветку (см. Указатели в git).

3.1 Базовые операций

Для создания ветки используйте

git branch <branch_name> [<start_commit>]

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

Опции git branch:

• -r | -a [—merged | —no-merged] — Список отслеживаемых внешних веток -r. Список и отслеживаемых и локальных веток -a. Список слитых веток —merged. Список не слитых веток —no-merged.
• -l, -f <имя-ветки> [<точка-начала>] — Список имён веток -l. Принудительное создание, перемещение или удаление ветки -f. Создание новой ветки <имя ветки>.
• -r (-d | -D) — Выполнить действие на отслеживаемой внешней ветке -r. Удалить слитую ветку -d. Принудительное удаление (даже не слитой ветки) -D.
• -m | -M [<Старая ветка>] <Новая ветка> — Переместить/переименовать ветки и ее журнал ссылок (-m). Переместить/переименовать ветку, даже если целевое имя уже существует -M.
• (-с | -С) [<старая-ветка>] <новая-ветка> — Скопировать ветку и её журнал ссылок -c. Скопировать ветку, даже если целевое имя уже существует -C.
• -v, -vv — Список веток с последним коммитом на ветке -v. Список и состояние отслеживаемых веток с последним коммитом на них.

Больше информации смотрите в git branch -h | —help.

Для переключения на ветку используйте git checkout . Также вы можете создать ветку выполнив git checkout -b <ветка>.

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

Для слияния 2 веток git репозитория используйте git merge .

Полезные параметры для git merge:

• —squash — Создать один коммит вместо выполнения слияния. Если у вас есть конфликт на ветках, то после его устранения у вас на ветке прибавится 2 коммита (коммит с сливаемой ветки + коммит слияния), но указав этот аргумент у вас прибавится только один коммит (коммит слияния).
• —ff-only — Не выполнять слияние если имеется конфликт. Пусть кто ни будь другой разрешает конфликты
• -X [strategy] — Использовать выбранную стратегию слияния.
• —abort — Отменить выполнение слияния.

Процесс слияния.
Если вы не выполняли на родительской ветке новых коммитов то слияние сводится к быстрой перемотке «fast-forward», будто бы вы не создавали новую ветку, а все изменения происходили прям тут (на родительской ветке).

Если вы выполняли коммиты на обеих ветках, но при этом не создали конфликт, то слияния пройдёт в «recursive strategy», то есть вам просто нужно будет создать коммит слияния что бы применить изменения (используйте опцию —squash что бы не создавать лишний коммит).
Если вы выполняли коммиты на обоих ветках, которые внесли разные изменения в одну и ту же часть одного и того же файла, то вам придётся устранить конфликт и зафиксировать слияние коммитом.

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

Разрешив конфликт вы должны завершить слияния выполнив коммит.

Во время конфликта вы можете посмотреть какие различия в каких файлах имеются.
git diff —ours — Разница до слияния и после
git diff —theirs — Разница сливаемой ветки до слияния и после
git diff —base — Разница с обеими ветками до слияния и после

Если вы не хотите разрешать слияние то используйте различные стратегии слияния, выбрав либо «нашу» версию (то есть ту которая находится на текущей ветке) либо выбрать «их» версию находящуюся на сливаемой ветке при этом не исправляя конфликт. Выполните git merge —Xours или git merge —Xtheirs соответственно.

3.3 Rerere

Rerere — «reuse recorded resolution” — “повторное использование сохраненных разрешений конфликтов». Механизм rerere способен запомнить каким образом вы разрешали некую часть конфликта в прошлом и провести автоматическое исправление конфликта при возникновении его в следующий раз.

Что бы включить rerere выполните

git config --global rerere.enabled true

Таrже вы можите включить rerere создав каталог .git/rr-cache в нужном репозитории.

Используйте git rerere status для того что бы посмотреть для каких файлов rerere сохранил снимки состояния до начала слияния.

Используйте git rerere diff для просмотра текущего состояния конфликта.

Если во время слияния написано: Resolved ‘nameFile’ using previous resolution. Значит rerere уже устранил конфликт используя кэш.

Для отмены автоматического устранения конфликта используйте git checkout —conflict=merge таким образом вы отмените авто устранение конфликта и вернёте файл(ы) в состояние конфликта для ручного устранения.

4. Указатели в git

в git есть такие указатели как HEAD branch. По сути всё очень просто HEAD указывает на текущую ветку, а ветка указывает на последний коммит в ней. Но для понимания лучше представлять что HEAD указывает на последний коммит.

4.1 Перемещение указателей

В книге Pro git приводится очень хороший пример того как вы можете управлять вашим репозиторием поэтому я тоже буду придерживается его. Представите что Git управляет содержимым трех различных деревьев. Здесь под “деревом” понимается “набор файлов”.
В своих обычных операциях Git управляет тремя деревьями:

• HEAD — Снимок последнего коммита, родитель следующего
• Индекс — Снимок следующего намеченного коммита
• Рабочий Каталог — Песочница

Собственно git предоставляет инструменты для манипулировании всеми тремя деревьями. Далее будет рассмотрена команда git reset, позволяющая работать с тремя деревьями вашего репозитория.

Используя различные опций этой команды вы можете:

• —soft — Cбросить только HEAD
• —mixed — Cбросить HEAD и индекс
• —hard — Cбросить HEAD, индекс и рабочий каталог

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

Примеру 1. Вы сделали 3 лишних коммита каждый из которых приносит маленькие изменения и вы хотите сделать из них один, таким образом вы можете с помощью git reset —soft переместить указатель HEAD при этом оставив индекс и рабочий каталог нетронутым и сделать коммит. В итоге в вашей истории будет выглядеть так, что все изменения произошли в одном коммите.

Пример 2. Вы добавили в индекс лишние файлы и хотите их от туда убрать. Для этого вы можете использовать git reset HEAD <files…>. Или вы хотите что бы в коммите файлы выглядели как пару коммитов назад. Как я уже говорил ранее вы можете сбросить индекс на любой коммит в отличий от git restore который сбрасывает только до последнего коммита. Только с опцией mixed вы можете применить действие к указанному файлу!

Пример 3. Вы начали работать над новой фичей на вашем проекте, но вдруг работодатель говорит что она более не нужна и вы в порыве злости выполняете git reset —hard возвращая ваш индекс, файлы и HEAD к тому моменту когда вы ещё не начали работать над фичей. А на следующей день вам говорят, что фичу всё таки стоит запилить. Но что же делать? Как же переместится вперёд ведь вы откатили все 3 дерева и теперь в истории с помощью git log их не найти. А выход есть — это журнал ссылок git reflog. С помощью этой команды вы можете посмотреть куда указывал HEAD и переместится не только вниз по истории коммитов но и вверх. Этот журнал является локальным для каждого пользователя.

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

5. Рекомендуемая литература

1. Pro git — Scott Chacon
2. Git для профессионального программиста — С. Чакон, Б, Штрауб
3. Git Essentials — F. Santacroce
4. Git: Version Control for Everyone (2013) — R. Somasundaram
5. Version Control with Git: Powerful tools and techniques for collaborative software development (2009) — J. Loeliger, M. McCullough
6. Practical Git and GitHub (2016) — D. Cruz
7. Git in Practice (2016) — M. McQuaid
8. Git Best Practices Guide (2014) — E. Pidoux
9. Learn Enough Git to Be Dangerous (2016) — M. Hartl
10. Learn Version Control with Git: A step-by-step course for the complete beginner (2014) — T. Günther
11. Git: Learn Version Control with Git: A step-by-step Ultimate beginners Guide (2017) — D. Hutten
12. Pragmatic Guide to Git (2010) — S. Travis
13. Волшебство Git (2016) — Б. Лин
14. A Hacker’s Guide to Git (2014) — J. Wynn
15. Practical Git and GitHub (2016) — D. Cruz
16. Deploying to OpenShift(2018) — G. Dumpleton
17. Git for Teams (2015) — Emma Jane Hogbin Westby

Git Guide

Everything you need to know about Git, from getting started to advanced commands and workflows.

What is Git?

Git is distributed version control software. Version control is a way to save changes over time without overwriting previous versions. Being distributed means that every developer working with a Git repository has a copy of that entire repository — every commit, every branch, every file. If you’re used to working with centralized version control systems, this is a big difference!

Whether or not you’ve worked with version control before, there are a few things you should know before getting started with Git:

• Branches are lightweight and cheap, so it’s OK to have many of them
• Git stores changes in SHA hashes, which work by compressing text files. That makes Git a very good version control system (VCS) for software programming, but not so good for binary files like images or videos.
• Git repositories can be connected, so you can work on one locally on your own machine, and connect it to a shared repository. This way, you can push and pull changes to a repository and easily collaborate with others.

Why Use Git?

Version control is very important — without it, you risk losing your work. With Git, you can make a «commit», or a save point, as often as you’d like. You can also go back to previous commits. This takes the pressure off of you while you’re working. Commit often and commit early, and you’ll never have that gut sinking feeling of overwriting or losing changes.

There are many version control systems out there — but Git has some major advantages.

Speed

Like we mentioned above, Git uses SHA compression, which makes it very fast.

Merge conflicts

Git can handle merge conflicts, which mean that it’s OK for multiple people to work on the same file at the same time. This opens up the world of development in a way that isn’t possible with centralized version control. You have access to the entire project, and if you’re working on a branch, you can do whatever you need to and know that your changes are safe.

Cheap branches

Speaking of branches, Git offers a lot of flexibility and opportunity for collaboration with branches. By using branches, developers can make changes in a safe sandbox.

Instead of only committing code that is 100% sure to succeed, developers can commit code that might still need help. Then, they can push that code to the remote and get fast feedback from integrated tests or peer review.

Without sharing the code through branches, this would never be possible.

Ease of roll back

If you make a mistake, it’s OK! Commits are immutable, meaning they can’t be changed. (Note: You can change history, but it will create new replacement commits instead of editing the existing commits. More on that later!) This means that if you do make a mistake, even on an important branch like main, it’s OK. You can easily revert that change, or roll back the branch pointer to the commit where everything was fine.

The benefits of this can’t be overstated. Not only does it create a safer environment for the project and code, but it fosters a development environment where developers can be braver, trusting that Git has their back.

Getting Started With Git

Depending on your operating system, you may already have Git installed. But, getting started means more than having the software! To get started, it’s important to know the basics of how Git works. You may choose to do the actual work within a terminal, an app like GitHub Desktop, or through GitHub.com. (Note: while you can interact with Git through GitHub.com, your experience may be limited. Many local tools can give you access to the most widely used Git functionalities, though only the terminal will give you access to them all.)

There are many ways to use Git, which doesn’t necessarily make it easier! But, the fundamental Git workflow has a few main steps. You can practice all of these in the Introduction to GitHub course.

Create a branch

The main branch is usually called main. We want to work on another branch, so we can make a pull request and make changes safely. To get started, create a branch off of main. Name it however you’d like — but we recommend naming branches based on the function or feature that will be the focus of this branch. One person may have several branches, and one branch may have several people collaborate on it — branches are for a purpose, not a person. Wherever you currently «are» (wherever HEAD is pointing, or whatever branch you’re currently «checked out» to) will be the parent of the branch you create. That means you can create branches from other branches, tags, or any commit! But, the most typical workflow is to create a branch from main — which represents the most current production code.

Make change (and make a commit)

Once you’ve created a branch, and moved the HEAD pointer to it by «checking out» to that branch, you’re ready to get to work. Make the changes in your repository using your favorite text editor or IDE.

Next, save your changes. You’re ready to start the commit!

To start your commit, you need to let Git know what changes you’d like to include with git add [file].

Once you’ve saved and staged the changes, you’re ready to make the commit with git commit -m "descriptive commit message".

Push your changes to the remote

So far, if you’ve made a commit locally, you’re the only one that can see it. To let others see your work and begin collaboration, you should «push» your changes using git push. If you’re pushing from a branch for the first time that you’ve created locally, you may need to give Git some more information. git push -u origin [branch-name] tells Git to push the current branch, and create a branch on the remote that matches it with the same name — and also, create a relationship with that branch, so that git push will be enough information in the future.

By default, git push only pushes the branch that you’re currently checked out to.

Sometimes, if there has been a new commit on the branch on the remote, you may be blocked from pushing. Don’t worry! Start with a simple git pull to incorporate the changes on the remote into your own local branch, resolve any conflicts or finish the merge from the remote into the local branch, and then try the push again.

Open a pull request

Pushing a branch, or new commits, to a remote repository is enough if a pull request already exists, but if it’s the first time you’re pushing that branch, you should open a new pull request. A pull request is a comparison of two branches — typically main, or the branch that the feature branch was created from, and the feature branch. This way, like branches, pull requests are scoped around a specific function or addition of work, rather than the person making the changes or amount of time the changes will take.

Pull requests are the powerhouse of GitHub. Integrated tests can automatically run on pull requests, giving you immediate feedback on your code. Peers can give detailed code reviews, letting you know if there are changes to make, or if it’s ready to go.

Make sure you start your pull requests off with the right information. Put yourself in the shoes of your teammates, or even of your future self. Include information about what this change relates to, what prompted it, what is already done, what is left to do, and any specific asks for help or reviews. Include links to relevant work or conversations. Pull request templates can help make this process easy by automating the starting content of the body of pull requests.

Collaborate (get feedback from tests or peers, make more commits locally and then push them up and get more feedback)

Once the pull request is open, then the real fun starts. It’s important to recognize that pull requests aren’t meant to be open when work is finished. Pull requests should be open when work is beginning! The earlier you open a pull request, the more visibility the entire team has to the work that you’re doing. When you’re ready for feedback, you can get it by integrating tests or requesting reviews from teammates.

It’s very likely that you will want to make more changes to your work. That’s great! To do that, make more commits on the same branch. Once the new commits are present on the remote, the pull request will update and show the most recent version of your work.

Merge into main

Once you and your team decide that the pull request looks good, you can merge it. By merging, you integrate the feature branch into the other branch (most typically the main branch). Then, main will be updated with your changes, and your pull request will be closed. Don’t forget to delete your branch! You won’t need it anymore. Remember, branches are lightweight and cheap, and you should create a new one when you need it based on the most recent commit on the main branch.

If you choose not to merge the pull request, you can also close pull requests with unmerged changes.

How to Use Git

Learning & Mastering Git Commands

If you’re getting started with Git, a great place to start is the Git Cheat sheet. It’s translated into many languages, open source as a part of the github/training-kit repository, and a great starting place for the fundamentals on the command line.

Some of the most important and most used commands that you’ll find there are:

• git clone [url]: Clone (download) a repository that already exists on GitHub, including all of the files, branches, and commits.
• git status: Always a good idea, this command shows you what branch you’re on, what files are in the working or staging directory, and any other important information.
• git branch: This shows the existing branches in your local repository. You can also use git branch [banch-name] to create a branch from your current location, or git branch --all to see all branches, both the local ones on your machine, and the remote tracking branches stored from the last git pull or git fetch from the remote.
• git checkout [branch-name]: Switches to the specified branch and updates the working directory.
• git add [file]: Snapshots the file in preparation for versioning, adding it to the staging area.
• git commit -m "descriptive message": Records file snapshots permanently in version history.
• git pull: Updates your current local working branch with all new commits from the corresponding remote branch on GitHub. git pull is a combination of git fetch and git merge.
• git push: Uploads all local branch commits to the remote.
• git log: Browse and inspect the evolution of project files.
• git remote -v: Show the associated remote repositories and their stored name, like origin.

Getting Started With GitHub

If you’re wondering where Git ends and GitHub begins, you’re not alone. They are tied closely together to make working with them both a seamless experience. While Git takes care of the underlying version control, GitHub is the collaboration platform built on top of it. GitHub is the place for pull requests, comments, reviews, integrated tests, and so much more. Most developers work locally to develop, and use GitHub for collaboration. That ranges from using GitHub to host the shared remote repository, to working with colleagues and capitalizing on features like protected branches, code review, GitHub Actions, and more.

The best place to practice using Git and GitHub is the Introduction to GitHub course.

If you already know Git and need to sign up for a GitHub account, head over to github.com.

Contribute to this article on GitHub.

  Перевод

  Ссылка на автора

Хотите начать работу с Git и GitHub? Вам нужно сотрудничать с командой? Вы работаете над проектом? Вы недавно обнаружили, что вам нужно быть на GitHub, если вы хотите, чтобы кто-то серьезно относился к вам в области технологий?

… вы действительно хотите внести свой вклад в первый проект с открытым исходным кодом?

Это для тебя!

С Git легко начать работу. Если вы быстро читаете (и не тратите много времени на регистрацию и установку), вы можете начать работу на GitHub примерно через десять минут.

Если вы пролистаете всю статью, вы можете попрактиковаться в клонировании существующего репозитория, создании ветки, внесении изменений и создании запроса на извлечение. Попутно вы также можете узнать, как найти свой терминал, использовать команды терминала и редактировать файл уценки (.md)!

Если вы делаете все это, поздравляю!

Вы внесете свой вклад в ваш первый проект с открытым исходным кодом — GitHub Welcome Wall !(Если вы хотите перейти прямо к вкладу с открытым исходным кодом, прокрутите вниз, пока не дойдете до раздела под названием «Давай сделаем это!«)

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

Давайте начнем!

Что такое Git? Что такое GitHub?

ГитВ настоящее время это технология контроля версий, которая подходит практически всем, от разработчиков до дизайнеров.GitHubэто социальная платформа для размещения кода, которая в настоящее время используется чаще, чем любая другая. Это место, где вы можете играть и экспериментировать. Это место, где вы можете найти (и поиграть) самую невероятную информацию с открытым исходным кодом, новейшие технологии, функции и проекты. Это место, где нужно учиться, и место, где можно принять участие. Вы можете хранить код там для работы или для школы, и вы можете взять какой-нибудь приятный код, который вы хотите изучить дальше. Вы даже можете размещать сайтыбесплатнопрямо из вашего хранилища! (Если вы хотите знать, как это сделать, прочитайте эту статью!)

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

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

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

Допустим, вы видите что-то вродеgit add <filename>, Это означает, что вы наберете, например,git add hello_world.pyесли вы хотите добавить файл с именем «hello_world.py» в свой репозиторий GitHub.

Я собираюсь дать вам много объяснений здесь, но это все терминальные команды, которые вам действительно нужно знать, чтобы начать:

git clone
git status
git add
git commit -m “ “
git push

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

Мы также поговорим о

git init
git branch
git merge
git checkout

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

git help

также очень полезно, если вы только начинаете! Мы тоже это обсудим.

(Если вы работаете на Mac, у вас уже есть терминал! Вы можете найти его, щелкнув по значку увеличительного стекла в верхнем правом углу экрана и выполнив поиск по слову «терминал».)

Шаг 1: Зарегистрируйтесь и установите!

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

Теперь зайдите в свой терминал и представьтесь Git! Чтобы установить ваше имя пользователя длякаждый репозиторийна вашем компьютере введите

git config --global user.name "<your_name_here>"

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

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

git config --global user.email "<your_email@email.com>"

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

Теперь вы готовы начать использовать Git на своем компьютере!

Для начала вы можете создать новый репозиторий на сайте GitHub или выполнитьgit initсоздать новый репозиторий из каталога вашего проекта.

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

Мне уже удобно с терминалом (Вариант 1)

Вот как вы можете начать прямо с терминала:

Если у вас есть каталог проекта, просто перейдите к своему терминалу и в вашем каталоге проекта выполните команду

git init 

Если вы хотите инициализировать ваш проект со всеми файлами в каталоге вашего проекта, запустите

git init .

включить все.

Допустим, у вас есть папка для вашего проекта с именем «new_project». Вы можете перейти к этой папке в окне терминала и добавить в нее локальный репозиторий, запустив

cd new_project
git init

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

git add <filename_one>

или беги

git add .

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

git commit -m "<add a commit message here>"

и если вы довольны своими изменениями, вы можете запустить

git push

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

git status

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

git add <filename>

или

git add --all

Затем передайте их с вашим сообщением и протолкните их.

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

Если у вас есть это, просто прокрутите вниз до «Учимся работать с другими »перейти к ветвлению и сотрудничеству!

Я не знаю, что вы только что сказали (Вариант 2)

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

Давайте сделаем это!

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

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

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

• Перейдите на веб-сайт GitHub, посмотрите в верхнем правом углу, нажмите знак +, а затем нажмите «Новый репозиторий».
• Назовите репозиторий и добавьте краткое описание.
• Решите, хотите ли вы, чтобы это был публичный или частный репозиторий
• Нажмите «Инициализировать этот репозиторий с помощью README», если вы хотите включить файл README. (Я определенно рекомендую сделать это! Это первое, на что люди обратятся, когда проверят ваш репозиторий. Это также отличное место для размещения информации, которая вам необходима, чтобы понять или запустить проект.)

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

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

Допустим, вы хотите внести некоторые изменения в свой файл README прямо на GitHub.

• Сначала зайдите в свой репозиторий.
• Нажмите на имя файла, чтобы вызвать этот файл (например, нажмите «README.md», чтобы перейти к файлу readme).
• Нажмите значок карандаша в верхнем правом углу файла и внесите некоторые изменения.
• Напишите короткое сообщение в поле, которое описывает сделанные вами изменения (и расширенное описание, если хотите).
• Нажмите кнопку «Подтвердить изменения»

Теперь изменения были внесены в файл README в вашем новом хранилище! (Я хочу обратить ваше внимание на маленькую кнопку, которую вы можете отметить на изображении выше, которая позволит вам создать новую ветку для этого коммита и запустить запрос на извлечение. Мы поговорим об этом позже!)

Довольно легко, правда?

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

Дай мне этот проект!

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

Для того, чтобыклонировать хранилищена свой компьютер, перейдите в репозиторий на веб-сайте GitHub и нажмите большую зеленую кнопку с надписью «Клонировать или скачать». (Вы можете загрузить репозиторий прямо здесь и пропустить содержимое терминала, если просто не можете с этим справиться. Но я верю в вас, поэтому продолжайте!) Убедитесь, что на нем написано «Клонировать с HTTPS». Теперь щелкните значок буфера обмена, чтобы скопировать его и вставить в буфер обмена (или выделите эту ссылку и скопируйте ее).

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

cd Desktop 

чтобы попасть на рабочий стол. Затем клонируйте свой репозиторий, чтобы его было легко найти. Чтобы клонировать репозиторий, вы набираете

git clone <that_thing_you_just_copied>

Просто! (Не забудьте изменить информацию между< >отметки к той строке букв и цифр, которые вы только что скопировали! Также убедитесь, что вы удалили< >.)

Если вы раньше не перемещались в своем терминале, вы можете медленно перемещаться с помощьюcdКомандуйте, пока не доберетесь туда, куда хотите Например, откройте свой терминал и введитеlsперечислить варианты того, куда вы могли бы пойти дальше. Вы можете увидеть «Рабочий стол» в списке, и вы можете просто набратьcd Desktopчтобы попасть на рабочий стол. Тогда вы можете запуститьgit cloneКоманда выше, чтобы клонировать ваш репозиторий прямо на ваш рабочий стол.

Вы можете увидеть некоторые имена пользователей вместо вариантов, например «Рабочий стол». В этом случае вам нужно выбрать пользователя, прежде чем вы увидите «Рабочий стол», поэтому выберите пользователя с помощьюcd <user>(замена<user>с именем пользователя), а затем введитеlsснова, чтобы увидеть ваш выбор. Очень вероятно, что сейчас вы увидите «Рабочий стол». Вы будете печататьcd Desktopесли вы видите рабочий стол в списке. А теперь иди с этим мерзавцем!

Если вы хотите вернуться на шаг назад в своем терминале, просто введитеcd ..

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

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

Если вы когда-нибудь захотите поиграть с проектом самостоятельно, вы можетевилкаэто на сайте GitHub вместо клонирования. Найдите в правом верхнем углу экрана кнопку «вилка» и нажмите ее. Это сделает копию репозитория в ваших репозиториях, чтобы вы могли играть самостоятельно, не делая ничего с оригиналом.

Теперь пришло время добавить несколько файлов в ваш проект!

Это все, что мы собираемся сделать:

git status
git add
git commit -m " "
git push

Не о чем беспокоиться!

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

Теперь проверьтеположение делвашего проекта!

Зайдите в свой терминал и зайдите в папку для своего хранилища. Тогда беги

git status

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

git add <fileneame>

В противном случае вы можете добавить все с

git add --all

или даже

git add .

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

Чтобы зафиксировать изменения, вы запустите процесс, запустив

git commit -m “<commit message>”

Вы вносите изменения в HEAD, но не в удаленный репозиторий. (Убедитесь, что вы заменяете это сообщение в кавычках своим ) После внесения изменений вы делаете «снимок» хранилища с помощью команды «commit». В этот «снимок» вы включите сообщение с -m.

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

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

git push

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

Вы можете увидеть, все ли обновлено в любое время, запустивgit statusкоманда!

Итак, теперь у вас есть репозиторий GitHub, и вы знаете, как добавлять файлы и вносить в него изменения!

Поздравляем !!!

Учимся работать с другими

Совместная работа — это название игры на GitHub!

GitHub поток

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

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

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

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

Также довольно просто создать ветку с именем «new_feature» в вашем терминале и переключиться на нее с помощью

git checkout -b new_feature

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

Давайте поговорим об оформлении заказа!

git checkout

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

git checkout master

или посмотрите на ветку «new_feature» с

git checkout new_feature

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

git merge new_feature

возьмет все изменения, которые вы внесли в ветку «new_feature», и добавит их в мастер.

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

git push --set-upstream origin new_feature

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

Ummmmm … что? Могу ли я сделать это на сайте?

Вы можете!

Один из способов сделать это — просто проверить кнопку, о которой мы упоминали ранее, когда редактировали файл README. Супер просто!

Вы также можете в любое время создать новую ветку прямо на веб-сайте, перейдя в свой репозиторий, щелкнув раскрывающееся меню в левой и средней части экрана с надписью «Branch: master», введя имя ветви и выбрав Ссылка «Создать ветку» (или нажмите Enter на клавиатуре). Теперь у вас есть две ветви, которые выглядят одинаково! Это отличное место для внесения изменений и их тестирования, прежде чем вы захотите, чтобы они повлияли на основную ветку.

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

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

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

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

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

Если вы участвуете в проекте, у людей в команде (или у рецензента) могут возникнуть вопросы или комментарии. Если вам нужно что-то изменить, это время! Если все хорошо, они могут развернуть изменения прямо из ветки для окончательного тестирования перед тем, как объединить их. И вы можете развернуть свои изменения, чтобы проверить их в производстве.

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

Обновить и объединить

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

git pull 

в вашем рабочем каталоге.

Чтобы объединить другую ветку с вашей активной веткой, используйте

git merge <branch_name>

Git попытается автоматически объединить изменения, но это не всегда возможно. Могут возникнуть конфликты. Если это произойдет, вам придется объединить конфликты вручную. После их изменения вы можете пометить их как объединенные сgit add <filename>, Вы можете просмотреть свои изменения, прежде чем объединить их с

git diff <source_branch> <target_branch>

Вы можете вернуться к главной ветке с помощью

git checkout master

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

git branch -d new_feature

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

git push origin <branch>

Другие полезные команды

Прежде всего, это мой любимый GitHub шпаргалка, Проверьте это для всех самых полезных команд Git!

Вы можете увидеть историю коммитов репозитория, если вы запустите

git log 

Вы можете увидеть коммиты одного человека с

git log --author=<name> 

Вы можете увидеть, что было изменено, но еще не поставлено

git diff

Нужна помощь, помня, какую команду вы должны выполнять? Пытаться

git help

чтобы увидеть 21 наиболее распространенных команд. Вы также можете напечатать что-то вроде

git help clone 

выяснить, как использовать определенную команду, например, «клон».

Давай сделаем это!

Почему бы не оставить свой след и приветствовать всех, кто здесь, чтобы узнать о Git и GitHub? Мы собираемся создать простую приветственную стену с заметками от всех, кто хочет опробовать Git и GitHub и внести свой вклад в их первый проект с открытым исходным кодом.

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

• Клонировать хранилище либо на сайте GitHub, либо запустив

git clone https://github.com/bonn0062/github_welcome_wall.git

• Создайте новую ветку и добавьте приветственную и вдохновляющую мысль в файл «welcome_wall.md». Вы можете сделать это на веб-сайте, но я настоятельно рекомендую вам попробовать клонировать репозиторий на ваш компьютер, открыть файл в вашем любимом текстовом редакторе и добавить туда свое сообщение. Это просто хорошее обучение!
• Создать пул-запрос,
• Напишите краткую заметку с описанием ваших изменений и нажмите зеленую кнопку, чтобы создать запрос на извлечение.

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

Поздравляем !!! Ты сделал это!

Как всегда, если вы сделаете что-нибудь удивительное с этой информацией, я хотел бы услышать об этом! Оставьте сообщение в разделе ответов или обратитесь в любое время в Twitter @annebonnerdata,

Спасибо за чтение!

Если вы хотите выйти или найти больше интересных статей, пожалуйста, присоединяйтесь ко мне в Простота содержания!