8 порад для більш ефективної роботи з Git

Привіт, мені здалося гарною ідеєю почати перекладати не тільки релизные пости з блогу ГитЛаба. Для розминки я взяв цей пост майже навмання, так що не судіть строго. Буду радий, якщо допоможете визначитися з вибором статті для перекладу, вибравши один з варіантів в опитувальнику


Git – це система контролю версій з величезною кількістю можливостей. Намагатися вивчити їх все досить утомливо, тому більшість користувачів обмежується використанням лише базового набору команд. У цій статті наведено кілька порад по роботі з Git, про яких ви, можливо, не знали. Ці поради допоможуть вам оптимізувати ваш процес розробки.

Аліаси
Одним з кращих способів спрощення роботи з Git є використання аліасів для часто використовуваних команд. Це допоможе зберегти час при наборі команд у терміналі.
Наприклад, аліаси команд
checkout
,
commit
та
branch
можна створити таким чином:
git config --global alias.co checkout
git config --global alias.ci commit
git config --global alias.br branch

Тепер замість
git checkout master
достатньо ввести
git co master
.
Також можна змінювати і додавати аліаси безпосередньо редагуючи файл
~/.gitconfig
:
[alias]
co = checkout
ci = commit
br = branch

Приховання (накопичення) змін до коміта
Уявімо, що в процесі роботи над новою фичей виникла термінова необхідність внести зміни в проект. Коммитить незавершену функціональність — не найкраще рішення, але втрачати всі напрацювання по ній теж не хочеться.
За допомогою команди
git stash
можна тимчасово скасувати внесені зміни, не видаливши їх остаточно:
$ git stash

Ця команда тимчасово приховує внесені зміни і залишає чисту робочу копію. Тепер можна переключитися на іншу гілку для внесення термінових змін, не оформлюючи вже зроблені зміни як коміти.
Щоб повернути приховану функціональність, достатньо ввести:
$ git stash pop

Якщо ж прихована функціональність більше не потрібна, її можна видалити за допомогою:
$ git stash drop

Порівняння комітів з командного рядка
Швидким і легким способом порівняння змін між коммитами або версіями одного і того ж файлу є використання команди
git diff
.
Для порівняння станів одного і того ж файлу між коммитами потрібно ввести:
$ git diff $start_commit..$end_commit -- path/to/file

Для порівняння змін між двома коммитами:
$ git diff $start_commit..$end_commit

Ці команди виведе результат в текстовому вигляді прямо в вікно терміналу. Для більш наочного результату можна використовувати
git difftool
. Ця команда запускає спеціальну програму для порівняння змін. Однією з таких програм є Meld.
Для налаштування Meld введіть:
$ git config --global diff.tool git-meld

Тепер її можна використовувати:
$ git difftool $start_commit..$end_commit -- path/to/file
# або
$ git difftool $start_commit..$end_commit

Відкат змін
Іноді при роботі над кодом стає зрозуміло, що внесені зміни виявилися непотрібними/невірними і їх необхідно відкотити. Замість того, щоб робити undo по кожній зміні, досить зробити reset файлів на HEAD-комміт гілки:
$ git reset --hard HEAD

Чи, для одного конкретного файлу:
$ git checkout HEAD -- path/to/file

Далі, якщо непотрібні зміни вже були закомічені, для їх відкату потрібно ввести:
$ git reset --soft HEAD~1

Більш ефективне використання Git blame
Git blame використовується для того, щоб дізнатися, хто вніс зміни в певну рядок файлу. Існує набір прапорів, які можна передавати цій команді, в залежності від того, що ви хочете вивести:
$ git blame -w # ігнорувати знаки табуляції
$ git blame -M # ігнорувати переміщення тексту
$ git blame -C # ігнорувати переміщення тексту в інші файли



Крім описаних вище порад по роботі з командами, існує кілька загальних порад по роботі з Git.
Робіть пулл часто
Якщо ви використовуєте GitLab Workflow, значить ви працюєте в гілках для виділеної функціональності (feature branches). Поки ви працюєте над фичей в окремій гілці, майстер-гілці може статися багато змін, деякі з яких можуть конфліктувати з доданими фічами.
Для того, щоб уникнути подібних конфліктів, потрібно як можна частіше пуллить зміни з майстер-гілки в вашу. Це дозволить вирішувати можливі конфлікти по мірі їх появи і зробить наступний мерж вашої гілки набагато більш легким.
Часті коміти, рідкісні пуши
Часті коміти логічно поділяють додану функціональність і дозволяють відкочувати окремі її частини при необхідності. Однак немає ніякої необхідності пушити кожен отримати на сервер: єдине, до чого це призведе – засмічення історії змін. Пушьте тільки тоді, коли ваша фіча готова.
Пуш тільки після тестування змін
Хорошим знаком того, що зміни готові до пушу, є успішне проходження тестів. Також це правило означає, що даний блок реалізується функціональності завершено, і можна переключити свої зусилля на наступний. Робіть пуш змін тільки після проходження всіх тестів, з подальшим їх повторним проходженням на стороні CI-сервера.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.