• Репозиторий — папка с файлами и настройками Git. Настройки расположены в скрытой папке .git.

• Форк ( fork ) — копия репозитория. GitHub создаст копию фокрнутого репозитория у вас на аккаунте. После этого в копию репозитория можно будет вносить изменения. Внесенные изменения можно предложить добавить в основной репозиторий через пул реквест.

• Клонить ( clone ) — скачивать репозиторий с удалённого сервера на локальный компьютер.

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

• Мастер ( master ) — главная или основная ветка репозитория.

• Коммит ( commit ) — фиксация изменений или запись изменений в репозиторий. Коммит происходит на локальном компьютере.

• Пул (pull ) — получение последних изменений с удалённого сервера репозитория.

• Пуш ( push ) — отправка всех неотправленных коммитов на удалённый сервер репозитория.

• Пул реквест ( pull request ) — запрос на слияние форка репозитория с основным репозиторием. Пул реквест может быть принят или отклонён владельцем репозитория.

• Мёрдж ( merge ) — слияние изменений из какой-либо ветки репозитория с любой веткой этого же репозитория. Чаще всего — слияние изменений из ветки репозитория с основной веткой репозитория.

• Код ревью ( code review ) — процесс проверки кода на соответствие определённым требованиям, задачам и внешнему виду.

• Обновиться из апстрима — обновить свою локальную версию форка до последней версии основного репозитория, от которого сделан форк.

• Обновиться из ориджина — обновить свою локальную версию репозитория до последней удалённой версии этого репозитория.

git config --global user.name "YourName"

• git — все команды для Git начинаются с этого слова.
• config — конфигурация.
• --global — означает, что настройка будет применена для всех проектов.
• user.name — настройка, которую нужно установить.
• YourName — имя, которое нужно установить.

git config --global user.email "[email protected]"

( имя и электронная почта )

git config --global --list

(--global, если настройки имени задавались для всех проектов и нужно вывести именно их)

Настройки хранятся в файле .gitconfig

cat ~/.gitconfig

(такого файла может не быть, если изначально не прописать настройки)

Настройки хранятся в файле .gitconfig

git help название_команды

(показать справку по выбранной команде)

git help

(покажутся самые популярные команды)

git help config

(покажется справка для команды config)

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

cd — название_папки — для перехода в выбранную папку.

cd .. — переместиться на одну папку назад.

сd / — переместиться на одну папку вперед.

cd - — вернуться к предыдущей папке.

cd ~ — перейти в папку, которая назначена домашней.

Пример:

cd /d

(перейти на диск D)

cd code/'some folder'

( перейти в папку "code", а затем в папку "some folder" — в коде она указана в кавычках, так как содержит пробелы )

ls — какие файлы есть в папке(список файлов).

ls -1 — какие файлы есть в папке, вывод в столбик.

ls -1 -a — какие файлы есть в папке, вывод в столбик, в том числе скрытых файлов. cd .. — подняться на уровень выше cd ../.. — подняться на 2 уровеня выше

Быстрые клавиши:

cd ~/D + tab — покажет, какие папки начинаются на букву "D".

cd ~/Des + tab — терминал сам допишет вместо "Des" — "Desktop".

start . — открыть папку, в которой сейчас находимся.

code . — открыть папку в редакторе кода.

start . — открыть папку, в которой сейчас находимся. start . ~/Desctop/Project/index.js — открыть файл в редакторе, назначенном по умолчанию для файлов данного типа.

code . — открыть папку в редакторе кода.

(превратить проект в репозиторий)

( если недавно его создали / он ещё не привязан к Git )

git init

После этого в папке с проектом появится скрытая папка .git, в которой содержится вся история изменений.

( проверяем, были ли добавлены новые изменения, которые ещё не внесены в историю изменений )

git status

(эта команда может использоваться довольно часто для проверки состояния репозитория)

Возможные варианты:

• Если выводятся файлы, выделенные красным — значит есть новые изменения, которые не добавлены. Иначе говоря — есть не отслеживаемые Git файлы.
• Если файлы выводятся зеленым — недавно измененные файлы добавлены. Иначе говоря — все файлы отслеживаются Git.
• Если нет подсвеченных файлов и надпись такого плана: "nothing to commit, working tree clean" — значит новых не внесенных изменений нет. Все файлы отслеживаются Git.

( для последующего сохранения состояния )

git add .

(проиндексировать все файлы в папке)

git add index.html

(проиндексировать только файл index.html)

git add css/button.css css/main.css

(проиндексировать сразу 2 файла, которые находятся в папке "css": button.css и main.css, указанные через пробел)

После: git status — можно проверить, проиндексировались ли все файлы.

( — закоммитить, сделать новые изменения отслеживаемыми )

Благодаря этой процедуре, в случае надобности — можно откатиться к предыдущему закоммиченному изменению. Иначе говоря: коммит — это как save в игре.

git commit -m "Описание, что изменилось"

После: git status — проверить, закоммитились ли файлы. Если да, будет сообщения такого плана: "nothing to commit, working tree clear".

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

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

git diff

(гит покажет, что именно изменилось в файле: красным — удаленное, зеленым — добавленное)

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

git diff --staged

git log

(покажет всю историю коммитов этого репозитория, если она есть)

git log -2

(покажет 2 последних коммита этого репозитория)

В консоли появится информация подобного рода:

commit c73af11e0830fe25cv4648c2356742f253cc000d (HEAD -> master, origin/master)
Author: YourName <name@mail.com>
Date:   Sun Feb 24 22:01:09 2019 +0300

    second commit

commit e5cdl7321di6love8the2rs1school687dde6282
Author: YourName <name@mail.com>
Date:   Sun Feb 24 21:50:20 2019 +0300

    first commit

c73af11e0830fe25cv4648c2356742f253cc000d — хэш второго коммита. Зная хэш коммита, можно заглянуть в лог коммита или откатиться к этому коммиту.

Также можно вывести историю всех коммитов в одну строку.

git log --oneline

Появится информация такого плана:

5c71719 (HEAD -> master) Уменьшили шрифт на кнопках
b69e1e8 Уменьшили шрифт телефона
2c8bd55 Заменили span на botton в кнопках для лучшей доступности
6bf8b41 Сделали рефакторинг
0c5e111 Починили ошибку фильтрации
5949091 Изменили основной шрифт
5d33d23 Установили цвет кнопок и фона
4f485ba Начали вести историю

git show e5mnd6f07fb3n72f9ccc3b24839687d61cde6282

(Вернуть файл в то состояние, в котором он был в последнем коммите. Например, если файл удален)

git checkout index.js

(теперь, если прописать git status, то будет видно, что файл не изменен)

git checkout c73af1de0877fe25eb4648c2356742f253cc000d index.js

(Когда изменения подготовлены и уже добавлены в индекс (git add), но выяснилось, что какой-то файл индексировать не нужно)

git reset HEAD index.js

(теперь, после проверки изменений git status, файл index.js не будет включен в индекс)

(Когда изменения подготовлены и уже добавлены в индекс (git add), но выяснилось, что какой-то файл индексировать не нужно)

git revert HEAD

(HEAD указывает на последний коммит, поэтому выполнили команду через него)

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

(Например, текст коммита был добавлен с ошибкой.)

git commit --amend -m "Правильное сообщение коммита"

(после этого последний коммит с неправильным текстом исчезнет из логов и хэш последнего коммита изменится — то есть не старый коммит поменялся, а создался новый коммит вместо старого)

git rm index.js

Осталось внести изменения в коммит, без внесения изменений в комментарий к нему:

Если прописать git status, будет следующее сообщение:

deleted: index.js

Поэтому можно изменить предыдущий коммит, убрав из него изменения:

git commit --amend --no-edit

git rm --сached index.js

Снова можно изменить прошлый коммит от внесения в него изменений:

Если прописать git status, будет такого плана информация:

deleted: index.js
Untrasked file: index.js

(файл останется, но от теперь будет неотслеживаемым)

git commit --amend --no-edit

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

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

git log --oneline

(вывести коммит в 1 строку, а не в 5 как обычно)
git cat-file -p b69e1e8

-p — выводит данные в удобном для чтения виде.

b69e1e8 — хэш коммита.

Выведется информация такого плана:

tree 9f390a90d40889a27d85910cb8b4530a02fd441e (состояние файлов на момент коммита)
parent 4f585bafe99v8bd57e2c82cf6a8b07569df8b810 (хэш родительского коммита)
author Viktor Tishchenko <name@mail.com> 1518978605 +0300 (два числа - это время ... )
committer Viktor Tishchenko <name@mail.com> 1518978828 +0300 (... когда был создан коммит )

• Обычно author и committer совпадают. Но это могут быть разные люди, если один разработчик изменил коммит другого.
• Коммит хранит не только состояние, но и: кто, когда, почему его сохранил. И ещё знает предыдущий коммит — коммит родителя.
• У самого первого коммита не будет родительского.

Если есть 3 коммита — мы по умолчанию находимся в последнем.

Когда мы коммитим — фиксируем состояние, то создается новый коммит и мы перемещаемся в него.

git commit -m "Описание, что изменилось"

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

git commit -m "Описание, что изменилось"

Если теперь запросить историю коммитов (git cat-file -p 8d54f00), то будет видна история только до 2-го коммита. Но это не значит, что все последующие коммиты исчезли.

Посмотреть все коммиты.

git log --oneline --all

Посмотреть все коммиты в виде схемы.

git log --oneline --all --graph

git checkout хэш_последнего_коммита

Git хранит кодовое слово, которое является указателем на последний коммит. Поэтому последнему коммиту всегда легко вернуться. По умолчанию это кодовое слово — master. А для сервера кодовое слово удаленного репозитория по умолчанию — origin.

(На любой коммит можно создать указатель)

git checkout -b yellow-design

(yellow-design — имя новой ветки)

Создать указатель на один из прошлых коммитов:

git checkout -b yellow-design хэш_коммита_которому_нужно_создать_указатель

При создании нового коммита с нового указателя, происходит ветвление коммитов и появляются ветки.

Ветка — вся история коммитов, приводящая в текущую точку.

Одна ветка master:

Вторая ветка yellow-design:

git checkout master

(перейти к ветке master)

Как понять, где мы находимся?

В логах. При запрашивании логов (git log --oneline), можно посмотреть по слову HEAD. Слово HEAD в логах показывает на наше текущее положение. Например:

(HEAD -> yellow-design)

(показывает, что мы находимся в ветке yellow-design)

В текущем состоянии. При запрашивании текущего состояние (git status) будет сообщение такого плана:

On branch yellow-design

(находимся в ветке yeallow-design)
...

git merge yellow-design -m "Объединили желтый дизайн и мастер"

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

Обычно основной веткой считается ветка master. От этой ветки могут отводиться другие ветвления. Которые в конечном счете могут снова объединиться в одну примкнув к основной ветке master.

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

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

CONFLICT (content): merge conflict in index.js

В этой ситуации есть 2 решения:

Для этого нужно отредактировать конфликтующие файлы вручную.

При решении вручную, в редакторе можно увидеть оформление кода такого плана:

<html>
  <head>
<<<<<<< HEAD
    <link rel="stylesheet" type="text/css" href="css/style.css" />
=======
    <link type="text/css" rel="stylesheet" href="style.css" />
>>>>>>> master
  </head>
  <body>
    <h1>Hello,World!</h1>
  </body>
</html>

Нужно убрать информацию от Git, а затем решить, какую строчку кода оставить.

После этого закоммитить изменения:

git commit -m "Решил конфликт при слиянии веток"

(например, если оно было вызвано по ошибке) следующей командой:

git merge --abort

(совмещение / преобразование)

Есть 2 ветки: master и feature.

git checkout feature

(переходим на ветку feature)

git rebase master

(перенести изменения из master в ветку yellow-design)

Теперь хэш коммитов C', D', E' не равен старому хэшу коммитов C, D, E в ветке feature. Но изменения в коммитах остались ровно такие же.

Преобразование делает дерево коммитов более линейным и красивым. Но оно не всегда уместно.

Когда НЕ использовать преобразование (git rebase):

• Если ветка является публичной и расшаренной. Переписывание общих веток будет мешать работе других членов команды.
• Когда важна точная история коммитов ветки (так как команда rebase переписывает историю коммитов).

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

git push --force

С этим флагом нужно работать аккуратно, потому что могут случайно уничтожиться какие-то важные файлы.

Подробнее про перебазирование веток.

(или другим сервисом, работающим с Git)

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

Удаленная ветка — не от слова "удалена", а от "удаленный сервер".

git remote add origin *ссылка*

origin — имя основного удаленного репозитория. Это не какое-то ключевое слово, так принято его называть.

Проверяем, что репозиторий добавился:

git remote -v

(-v — значит подробный)

Выведет:
origin *ссылка* (fetch) (забирать из него изменения)
origin *ссылка* (push) (отправлять туда изменения)

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

git remote get-url origin

git remote get-url origin

-u — в случае, если находимся, например в не основной ветке yellow-design, но хотим установить связь с основной веткой master.

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

git push origin master

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

Если нет авторизации в консоли, при попытке запушить изменения в удаленный репозиторий (git push origin master), Git может выдать подобную ошибку:

Permission denied (publickey).

fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.

Но так обычно происходит, если при установке GitBash не был включен пункт "Enable Git Credential Meneger". Тогда некоторые средства авторизации, в том числе логин и пароль при каждом запросе понадобится вводить заново.

Как установить SSH-ключ.

Например, хотели назвать comments, а напечатали cmments.

git push origin cmments:comments

cmments — имя локальной ветки, которую создали с ошибкой. comments — имя ветки на удаленном сервере с уже правильным названием, куда нужно запушить файлы.

Так можно отправить любую локальную ветку на любую удаленную на ветку.

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

git push origin :сmments

Ведь неправильная написанная ветка всё ещё осталась на компьютере.

git branch -m comments

Команда git branch может: переименовывать, удалять и создавать ветки.

Скачивание и запись на сервер изменений.

На темном фоне — изменения, которые внесены на удаленном сервере.

На светлом фоне — изменения, которые есть на локальном компьютере.

( получить изменения из удаленного репозитория )

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

git pull origin master

(забирает и сливает коммиты и ветки)

Получится:

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

git fetch origin

(только забирает коммиты и ветки)

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

Команда git pull эквивалентна комбинации git fetch и git merge.

git branch --set-upstrim-to=origin/comments

git branch -vv

-v — подробно.

-vv — очень подробно.

Vim — по умолчанию редактор текстовых файлов в GitBash.

:q — выйти с редактора

:q! — выйти с редактора, если через него что-то менялось

Алиас — простое кодовое значение команды или нескольких команд. Некоторые команды в консоли вводить долго и неудобно. Поэтому можно создать их алиас.

git config --global alias.с config

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

Другой пример:

git config --global alias.сg 'config --global'

cg — теперь набирая эту одну команду будут срабатывать сразу две команды config --global.

1. Уроки: https://githowto.com/ru
2. Руководство: https://github.com/k88hudson/git-flight-rules/blob/master/README_ru.md
3. Ещё руководство: http:https://firstaidgit.ru/#/
4. Большое руководство Стэнфорда: http:https://www-cs-students.stanford.edu/~blynn/gitmagic/intl/ru/
5. Книга: https://git-scm.com/book/ru/v2
6. Скринкасты: https://www.youtube.com/playlist?list=PLDyvV36pndZHkDRik6kKF6gSb0N0W995h

Original work link →