Шпаргалка – Git

Git – потужна та досить популярна розподілена система керування версіями файлів. Щоб збагнути Git потрібно прочитати декілька книжок і роки практики. В цій статті ви знайдете шпаргалку по всім основним командам Git.

Я постарався згрупувати команди.

git remote #переглянути віддалені репозиторії

Відміна операції, або як змінити коментар останнього коміту.
Якщо Ви забулись щось добавити, а вже виконали коміт або хочете поміняти коментарій коміту, то можна виконати коміт з цим параметром. Це дозволить змінити коментарій, а за потреби можна добавити файл.

git commit -m "Change file";
git add forgottenFile;
git commit --amend;

Якщо випадково добавили більше файлів ніж потрібно , наприклад, git add . а потрібно було лише парочку, то команда допоможе прибрати файл з підготовки до коміта (при цьому він не буде змінений)

git reset HEAD

Щоб повернути файл до його стану з репозиторію достатньо виконати наступну команду (це аналог svn revert <file>)

git checkout -- <file>

В Git існують анотовані мітки та легковагові мітки. щоб створити анотовану достатньо набрати git tag -a v1.5 -m "comment for version 1.4"
Щоб додати легковагову мітку достатньо виконати git tag v1.4. Мітки можна додавати й до вже пройдених комітів, для цього можна ввести контрольну суму або її частину, як приклад git log --pretty=oneline – поверне нам контрольну суму, яку потім можна ввести в команду git tag -a v1.2 fdsfds32
Щоб відправити мітки на сервер не достатньо просто ввести git push, потрібно ввести ім’я мітки git push origin <імя мітки>, а якщо міток багато, можна додати параметр –tags, git push origin --tags

#подивитись таги, з параметром -l 'tekst' знайде текст з кавичок
git tag -l 'search';

В Git можна додавати аліаси до команд котрі вже існують. Наприклад, наступна команда додасть аліас co для команди checkout

git config --global alias.co checkout;

Спрощений статус можна переглянути за допомогою команди status та параметру -s.

• ?? – нові файли котрі не додано до слідкування
• A – добавлені до слідкування
• M – модифіковані не проіндексовані
• MM модифіковані і проіндексовані

git status -s | --short;

Переглянути логи можна за допомогою команди git log

git log -p -2
# -p покаже різницю в файлах, -2 кількість комітів до показування
 
git log --stat 
# скорочена статистика для кожного коміту. 
# Опція --stat друкує під кожним з комітів список і кількість змінених файлів, 
# а також скільки рядків в кожному з файлів було добавлено та видалено
 
git log --pretty=<parametr>
# відформатований вигляд в залежності від параметру котрий буде передано.
# oneline - кожний коміт в один рядок
# short
# full
# fuller

Логи комітів теж можна вивести в більш привабливій формі

git log --pretty=format:"%h - %an, %ar : %s";
# %h - скорочений хеш коміту
# %an - імя автора
# %ar - відносна дата автора
# %s - зміст (коментарій до коміту)

Існують такі параметри:

• %H хеш коміту
• %h скорочений хеш коміту
• %T хеш дерева
• %t скорочений хеш дерева
• %P хеш предка
• %p скорочений хеш предка
• %an ім’я автора
• %ae електронна пошта автора
• %ad дата автора (формат дати можна задати опцією –date=option)
• %ar відносна дата автора
• %cn ім’я комітера
• %ce електронна пошта комітера
• %cd дата комітера
• %cr відносна дата комітера
• %s зміст

Вам напевно цікаво, яка ж різниця між автором і комітером. Автор – це людина, котра спочатку зробила роботу, а комітер – це людина, яка останнім застосувала цю роботу. Іншими словами, якщо ви створите патч для якогось проекту, а один з основних членів команди цього проекту застосує цей патч, ви обидва отримаєте статус учасника – ви як автор і основний член команди як комітер.

git log --pretty=format:"%h %s" --graph;
# параметр --graph покаже лог у вигляді ASCII графу, 
# котрий покаже актуальну гілку і історію зливання гілок

До найбільш розповсюджених опцій команди git log можна віднести

• -p Показує патч для кожного коміту
• –stat Показує статистику змінених файлів для кожного коміту
• –shortstat Показує тільки рядок з кількістю змін / вставок / видалень для команди –stat
• –name-only Показує список змінених файлів після інформації про коміт
• –name-status Показує список файлів, які додані / змінені / видалені
• –abbrev-commit Показує тільки кілька символів SHA-1 чек-суми замість всіх 40
• –relative-date Показує дату у відносному форматі (наприклад, “2 weeks ago”) замість стандартного формату дати
• –graph Показує ASCII граф з розгалуженням та історією злиттів
• –pretty Показує коміти в альтернативному форматі. Можливі варіанти опцій:
  • oneline
  • short
  • full
  • fuller
  • format (за допомогою цієї опції ви можете вказати свій формат)

git log --since=2.weeksж
# покаже список комітів зроблених за останні два тижня, також ще є --until
# дати можна вказувати на різний спосіб, наприклад 2019-02-15 або 2 years 1 day 3 minutes ago
 
--autor # можна фільтрувати по автору

--grep # шукати по ключовим словам в коментарі коміту

--all-match # якщо хочемо щоб всі фільтруючі фрази брали участь. 
# Для прикладу якщо фільтруємо по автору і фразі багфікс, 
# то без цього параметру покаже співпадіння з автору або коментарю, а з цим параметром по автору і коментарю.

-S # як аргумент приймає рядок і показує тільки ті коміти, 
# в яких було змінено такий рядок. Наприклад, зміни конкретної функції
git log -Smd5;

Існують опції для обмеження виводу команди git log

• -(n) – показує тільки n останніх комітів
• –since, –after – показати коміти, які було зроблено після вказаної дати
• –until, –before – показати коміти, які було зроблено до вказаної дати
• –author показує тільки коміти, в яких запис співпадає з вказаним рядком
• — committer показує тільки коміти, в яких запис автор співпадає з вказаним рядком
• –grep показує коміти, повідомлення яких містить вказаний рядок
• -S показує тільки ті коміти, в котрих було добавлено або видалено вказаний рядок

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

Гілки в Git

Гілка master це не спеціальна гілка, це точно така ж гілка як і всі інші. Існує майже у всіх репозиторіях лише через те, що її створює команда git init і більшість людей не міняє її назви.
Git визначає в якій гілці ви знаходитесь за допомогою вказівника HEAD. Щоб побачити на що саме посилається Git можна виконати команду git log --oneline --decorate , отримаємо щось на кшталт 3382b22 (HEAD -> master, origin/master), або git branch без параметрів, буде показано всі гілки а перед тою на яку посилається HEAD буде стояти зірочка *.

Щоб створити нову гілку достатньо виконати наступні команди:

git branch branchName; # створити бранч
git checkout branchName; # переключитись на бранч
# Після переключення на іншу гілку, HEAD буде вказувати на вашу нову гілку 
# "3382b22 (HEAD -> branchName, origin/master, master)"

git checkout -b branchName; # створити гілку і одразу переключитись на створену гілку

git branch -v # покаже останній коміт кожної з гілок

git branch --merged # покаже нам гілки які вже було змержовано
git branch --no-merged # покаже нам гілки які не змержовано

# Щоб видалити гілку використовуємо параметр -d
git branch -d branchName;

git push origin --delete branchName; # видалити з серверу
# Видаляється вказівник на сервері, зазвичай дані залишаються на якийсь період, 
# допоки не запуститься збирання сміття

Отримання та зливання коду

В Git існує два методи внесення змін з одної гілки до іншої: зливання merge і перетворення (переміщення) rebase.

• merge – Робить трьохстороннє зливання між останніми знімками гілок і самого недавнього спільного для цих гілок батьківського знімку, створюючи при цьому новий знімок і коміт.
• rebase – дозволяє взяти всі зміни котрі було зафіксовано (commit) в одній гілці і застосувати їх до іншої гілки

В обох випадках, ви отримуєте той самий результат, відмінність лише в історії комітів, перетворення (rebase) робить історію чистішою.
Єдина увага: не виконуйте перетворення (rebase) вже відправленних комітів до публічного репозиторію!
Адже коли ви щось перетворюєте (переміщуєте) ви відміняєте існуючі коміти і створюєте нові, похожі на старі, але вони являються іншими.

Корисні короткі команди

# git pull це те саме що по черзі виконати git fetch; git merge;
git pull === git fetch; git merge;

git diff # показує зміни
git diff --check # показує зайві пробіли, які ми навряд чи хотіли б скомітувати
git describe <гілка> # генерація номеру збірки, як приклад v.1.5.2-rc1-20-hash

git archive master --prefix='project/' | gzip > `git describe master`.tar.gz # реліз збірки
# дана команда створить архів з кодом з мастера в папкі project. 
# Також можна додати параметр --format=zip і створити архів без пайпа на gzip: 
git archive master --prefix='project/' --format=zip > `git describe master`.zip;

Приховування змін для подальшого використання

Якщо ви працюєте, вам потрібно переключитись на іншу гілку, а ви ще не хочете робити коміт, то вам на допомогу прийде команда git stash. Достатньо ввести її і ваші зміни буде збережено в спеціальному місці, щоб подивитись список збережених змін виконайте команду git stash list. Щоб відновити зміни, достатньо виконати команду git stash apply. Якщо у вас було декілька прихованих змін, можна відновитись до конкретної, для прикладу git stash apply stash@{2}. Щоб видалити всі записані приховані зміни достатньо виконати команду git stash drop. Також можна виконати git stash pop щоб примінити приховані зміни і одразу видалити їх з місця їхнього зберігання.

Також можна приховати зміни і одразу створити бранч, для цього git stash branch <branchName>;

Вирішення конфліктів

Конфлікти можна вирішити по різному. Якщо проблема виникла, наприклад, через пробіли/табуляцію чи різні закінчення рядків (Linux/Windows style) то можна спробувати зробити merge з параметрами -Xignore-all-space (ігнорує будь-яку кількість існуючих символів пробілу) або -Xignore-space-change (ігнорує всі зміни з символами пробілів).

Також, конфлікти можна вирішувати в ручну. Коли наше репо знаходиться в стані конфлікту, можна отримати 3 версії файлу: нашу, їх та спільну (загальну). Можна це зробити за допомогою наступних команд:

git show :1:test.file > test.common.file;
git show :2:test.file > test.ours.file;
git show :3:test.file > test.theirs.file;

Тепер маючи 3 файли, можемо за допомогою команди git merge-file виконати їхнє зливання.

git merge-file test.ours.file test.common.file test.theirs.file > test.file