15 порад по Git для ефективної роботи кожен день

Ця замітка — спроба пояснити ті базові налаштування і прийоми, якими я користуюся кожен день. Рецепти не претендують бути ноу-хау, але можуть допомогти з освоєнням щоденної гігієни роботи з репозиторієм.

1. Використовуй свіже

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

> git --version
git version 2.27.0

2. Налаштуйте інструмент

Налаштуйте собі публічний email не афілійований з поточною компанією. Це дозволить вам тонко налаштовувати ідентифікацію під різні репозиторії та не замислюватися про налаштування за замовчуванням, а GitHub буде показувати вашу активність, навіть якщо ви зміните місце роботи.

> git config --global user.email "name@example.com"> cd company_project
> git config user.email "name@example.com"

Якщо ви не користуєтеся консоллю та vim'ом для редагування, то вам варто налаштувати ваш редактор:

> git config --global core.editor "code --wait"

3. Налаштуйте autocomplete

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

Читайте: Що таке pull request?

Git з коробки надає набір скриптів для автокомпліта, але якщо ваш shell, як у мене, більш екзотичний — знайдіть і поставте автокомпліт саме для нього.

4. Прискорюй те що часто використовується

Налаштуйте собі псевдоніми (aliases) для швидкої роботи. Для кожної людини зручність відчувається по-різному і я не рекомендую захоплюватися псевдонімами на одну літеру, особливо якщо ви часто працюєте на інших робочих станціях чи використовуєте ssh для віддаленої роботи на серверах — вам або доведеться витрачати час на боротьбу з відмінностями, або розтягувати свій файл налаштувань по всім машинам (що не завжди погано, звичайно). Також не намагайтеся замінити псевдонімами будь-яке поєднання команд — половину ви забудете, а на половині звикнете більше, ніж воно того заслуговує.

Я перейшов на Git з SVN, тому для мене базові псевдоніми перекочували звідти, а "b" — єдиний однолітерний псевдонім.

> git config --global alias.st "status -sb"> git config --global alias.co "checkout"> git config --global alias.ci "commit -a"> git config --global alias.b "branch"

5. Оглядовість допомагає розв'язувати проблеми

Я часто працюю з історією проєкту — потрібно зрозуміти, що і коли влилося та які стани проєкту цьому передували. Часто важливо знати послідовність комітів і топологію дерева історії. Git з коробки допомагає показати дерево історії проєкту:

> git log --oneline --graph --branches

Але для повноти картини хочеться бачити й авторів, дати в зручному забарвленні, бо мій псевдонім виглядає не так доброзичливо з параметром --pretty=format::

> git log --graph --date=short --branches --pretty=format:'%C(yellow)%h%C(reset) %ad | %C(75)%s%C(reset) %C(yellow)%d%C(reset) [%an]'

6. Слідуй за протоколом

Завжди клонуйте репозиторій, в який вносите правки git+ssh протоколу, це працює швидше ніж по http і заощадить час в процесі роботи:

> git clone git@github.com:gurugray/gurugray

7. Розділяй джерела

Якщо ви працюєте з репозиторіями за «форковою» моделлю (коли до основного сховища є доступ тільки на читання, а всі pull-request'и подаються з форк) називайте основний репозиторій upstream це допоможе не плутатися в командах відведення гілок і push'а в свій origin. Не забувайте про протокол, якщо репозиторій відкрито тільки для читання, то його можна клонувати без ssh-шару, що теж дасть економію часу в процесі роботи:

> git clone git://github.com/gurugray/gurugray -o upstream

8. Контролюй процес

Не використовуйте команду pull, це складова команда і робить кілька дій відразу. Часто при роботі з репозиторієм новачки допускають помилку не розуміючи, як ця команда оновлює поточну гілку, і засмічують свою історію або неправильно працюють з дефолтною гілкою. Я рекомендую явно оновлювати репозиторій локально, потім явно оновлювати свою гілку:

> git fetch --all
> git rebase my_feature upstream/master

9. Не вводь себе в оману

Ніколи не зберігайте дефолтну гілку локально, завжди відводьте гілку від актуальної віддаленої, це дозволить уникнути плутанини й точно знати від чого і в який час ви відвели гілку:

> git fetch --all
> git checkout -b my_feature upstream/master

> git branch -master D

10. Не бійся виправляти

Якщо ви стежите за чистотою історії та хочете виправити стан проєкту зафіксоване кілька комітами тому, то досить зробити коміт з параметром --fixup= і передати потрібний хеш коміта для подальшого причісування історії

> git commit -m "Feature A is done"> ...
> git commit -m "Feature B is done"> git commit --fixup=fe2f857

> git log --oneline
a5050e7 fixup! Feature A is done
633e33f Feature B is done
...
fe2f857 Feature A is done
cb5db88 Previous commit

11. Не бійся швидко виправляти

Один з корисних псевдонімів — заміна останнього коміта поточним станом, дозволяє «підклеїти» поточний стан до останнього зафіксованого, при цьому не включаючи режим редагування повідомлення:

> git config --global alias.fixlast "commit --all --amend --no-edit"

12. Перебазовуй

Навчіться і користуйтеся командою rebase в інтерактивному режимі з параметром --autosquash з яким використання --fixup буде ще зручнішим, а сам rebase допомагає причісувати історію й акуратно оформити коміти, наприклад за прийнятим у вас guidline, до подачі pull-request'а для успішного його прийняття.

> git rebase -i --autosquash cb5db88
pick fe2f857 Feature A is done
fixup a5050e7 fixup! Feature A is done
pick 733e2ff Feature B is done

> git log --oneline
633e33f Feature B is done
...
5778cbb Feature A is done
cb5db88 Previous commit

13. Скидай непотрібне

Навчіться і користуйтеся командою reset вона дозволить легко маніпулювати локальною історією і станом, наприклад після низки правок і комітів на код-рев'ю «з'яднати» останні непотрібні стани простіше з її допомогою:

> git reset @~4
> git commit --all

14. Контролюй деструктивний push

Якщо ви хочете запушити змінену історію, раджу використовувати повний синтаксис команди та не використовувати ключ --force f, це дозволить не звикати до налаштувань за замовчуванням і не призведе до випадкового перетирання історії на сервері:

> git push origin +feature

15. Пам'ятай про літописця

Не забувайте про reflog ця команда допоможе розібратися з проблемами в локальному сховищі якщо щось пішло не так — рятівне коло для новачків, до якого вони рідко підходять:

> git reflog
> ...
> git reset --hard FOUND_HASH

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

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