Thread by @gurugray

Сказали, что всё ещё актуально — делаю.
Один лайк — один факт (забавный, забытый, неизвестный, полезный) про #git.
Стартую с 30 лайков чтобы дать себе фору. Go

Быстро вы, ок начнём с простого:

1) #git использует простую концепцию:
4 типа хранимых объектов — blob, tree, commit, annotated tag и два типа ссылок — reference (branch, tags), symbolic reference (HEAD, ORIG_HEAD etc)

Всё остальное тулинг для работы с этими сущностями.

2) Хранение истории организовано в виде направленного графа без циклов (DAG), а в частности «дерева». Однако её можно расширить до состояния «леса» используя orphan ветки. blog.gurugray.ru/post/238936637…

2.1)
Недавно мне прислали ссылку что это меняют введением «замыканий» веток m.habr.com/ru/post/445676/ (что натолкнуло меня на написание этих заметок)

3)
До версии 2.x команда push с параметром --force форсировано пушила историю всего репозитория затиранием всех веток, которые трекались.

С тех пор я советую использовать полный синтаксис push remote +branch для контроля ситуации

monkeyuser.com/2017/it-hell/ есть отдельное место в аду, кстати

4)
Многие, даже сейчас, не видят разницы между merge и rebase. И в большинстве случаев на маленьких проектах — это не столь важно, главное понимать суть работы с объектами и патчами.

5)
Git работает с состояниями проекта, а не с изменениями. Каждый комит — это фиксация конкретного состояния, изменения же «патчи» всегда высчитываются в рантайме.

6) Про доки
Не советую для первого чтения git-scm.com/book/en/v2/Git…
Лучше почитайте think-like-a-git.net

7)
В репозитории можно создавать «скрытые» ветки — git update-ref refs/hidden/branch branch, такими являются все референсы вне папки refs/heads

На GitHub'е так, в частности, реализованы ссылки на пулл-реквесты help.github.com/en/articles/ch…

8)
Скрытые ветки или так называемые «неймспейсы» можно создавать в удалённом репозитории, например на GH — git push upstream +BRANCHANME:refs/namespace/BRANCHANME

Но работа таких веток не регламентированна и зависит от работы вашего remote'а

9) Чтобы предотвратить затирание важных публичных веток включите "protected" ветки (не все про них знают / помнят), если у вас GH, или попробуйте настроить свой remote с помощью админа этого сервера

10) В git можно писать свои хуки как на сервере, так и локально git-scm.com/book/en/v2/Cus…
Это обычные shell-скрипты, которые помогут вам настроить свой workflow.

Для быстрого создания таких на проекте можно использовать готовый фреймворк, например github.com/typicode/husky

11) Для действий с файлами в git можно писать свои «драйвера» это позволяет манипулировать файлом в момент добавления / удаления / слияния: git-scm.com/docs/gitattrib…, как пример — реализация git-lfs

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

Для решения этой проблемы было придумано много инструментов, одним из актуальных на сегодня является git-lfs от GitHub'а git-lfs.github.com

13) Git не занимается ни аутентификацией, ни авторизацией. В комит-месадже пишутся атрибуты которые вы зададите — git commit --author="" --date=""

А вот запушить в remote вы сможете только если вам разрешит сервер (GitHub, например)

13.1) Для демонстрации работы такой возможность есть проект для лулзов, например github.com/gelstudios/git…

14) Многие боятся rebase и reset, потому что он «стирает мои комиты», однако никакая информация зафиксированная локально не трётся (ну вменяемое время) — для её просмотра и восстановления можно пользоваться командой reflog git-scm.com/docs/git-reflog

15) И про редкое — в git есть механизм «записок» или «приписок» к комитам: git-notes позволяет дописывать к комитам заметки не меняя их хэш-суммы. Однако сложность поддержки этих заметок довольно высокая и они не пользуются популярностью. git-scm.com/docs/git-notes

16) Ещё про редкое. Мы всегда говорим о неизменяемой истории и объектах фиксируемых в ней.
Но «если очень хочется, то можно» — команда git-replace, позволяет заменить любой объект git-scm.com/docs/git-repla…, однако у неё куча условностей и ограниченная поддержка тулинга.

17) Я люблю работать в консоле.
У git-log есть куча параметров, одни из моих любимых --graph --oneline — позволяют визуализировать граф коммитов и найти нужный merge визуально. git-scm.com/docs/git-log

18) Ещё про лог.
Если в merge-commit'ах писать номер задачи, то их лего будет грепать даже в автоматическом режиме: git log --grep "SERP-2019"

19) Конечно пользоваться в консоли полными командами не очень удобно. Вообще git из коробки не даёт сокращённых команд и с помощью алиасов можно настроить себе любое сочетание.
Минус в том, что придётся носить свой конфиг с собой. git-scm.com/book/en/v2/Git…

20) В git'е есть свой DSL для обхода дерева истории:
@ — текущий HEAD
@~2 — два шага назад по истории в «основной линии»
@^2 — второй родитель комита

@~2^2~3 — вполне себе удобно ;)
atlassian.com/git/tutorials/…

21) Да, в догонку, git не ограничивает количество родителей, merge-коммит, это лишь состояние к которому прилинкованы ссылки на предыдущие ;)
Я сам сливала в один комит порядка 80 разных веток.

Т.е. реф @^5 волне себе валидная запись, если таковой родитель имеется ;)

после небольшого перерыва…

22) git-lfs решает часть проблем, но приносит новые — ещё один уровень абстракции, тулинг рядом — хуки и драйвера, что сильно повышает порог входа.

MS пошли другим путём — виртуальная файловая система: vfsforgit.org

Вы продолжаете лайкать — я продолжаю писать (хотя кажется нужно было забиться на ретвиты :))

23) Продолжая тему тулинга.
В git можно использовать merge-tool — внешний инструмент для слияния файлов, например разницу в структурированных фалах json или мета-информацию в jpeg ;) git-scm.com/docs/git-merge…

24) Да и помимо merge-tool есть ещё merge-driver, и если первое — в основном упрощает работу по слиянию для пользователя в виде GUI, то второе именно про автоматизацию:
npmjs.com/package/npm-me…
npmjs.com/package/git-po…
etc.

25) В git есть команда stash — по описанию удобно пользоваться для незаконченных фич.
Однако я не рекомендую её использовать — просто «комитьте и пуште» в свою ветку, потом не забудьте причесать ;)

Stash — организован посредством веток, но это не очень удобный тулинг.

26) Не все знают или забывают про «алиасы» на удалённые репозитории в .gitconfig.

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

git clone ght:gurugray/talks.git
git remote add ght:partner/talks.git

git-init.ru/2013/post/inst…

27) Используя «графовую» природу git'а можно делать различные поделки, например:
— изотерический язык программирования morr.cc/legit/
— генеалогическое habr.com/ru/post/351158/
(спасибо подписчикам ;))