Комментарии 21
ветвь -> ветка
а чем ветка отличается от коммита? Не считая человеческого названия
Тем, что если в ветке сделать новый коммит, то можно потом по имени ветки переключиться на него. И так сколько угодно раз. А если сделать коммит, не будучи "на ветке", то нужно будет запоминать хэш нового коммита, или же старательно его потом искать, чтобы переключиться. И так для каждого нового коммита сверху.
Но в целом да, ветка это всего лишь именованный указатель на коммит, который при этом умеет автоматически двигаться на дочерний коммит.
Ветка состоит из коммитов и головы.
Про гит удобно думать как про сохранения в игре. Каждый коммит это сохранение, ветка это объединенная цепочка сохранений, до мерджа сохранений в играх додумались только моддеры, но и их можно понять.
HEAD это то сохранение, которое загрузится, если в главном меню нажать "продолжить".
Detached HEAD это когда то прохождение, которое идет сейчас не сохраняется в слот сохранений.
Ветка в этих определениях это слот сохранений. (Предполагая что в слоте может быть куча сохранений)
тем что коммит - статичный
а при работе с веткой обычно подразумевается последний коммит в этой ветке, а не какой-то промежуточный, и он может меняться.
Если совсем вкратце:
Коммит - это конкретный набор изменений, включающий кроме изменений в файлах, ещё и сообщение о внесённых изменениях, имя автора, дату и т.п
Ветка - это именованная ссылка на определенный коммит.
Не совсем так. Коммит в Git - это полный снимок (snapshot) всей рабочей директории в определенный момент времени, просто внутреннее хранилище работает по принципу адресации по содержимому, что позволяет использовать ранее созданные объекты, пока не поменялось их содержимое.
Изначально Git сохраняет не отдельные измененные строки в файле, а содержимое файла полностью. При этом даже не в момент фиксации нового коммита, а при добавлении файла в индекс.
Хотя в дальнейшем для оптимизации объема данных может "сжать" версии файлов в один pack, который формируется по принципу наиболее актуальный снимок + дельты для формирования предыдущих снимков.
А зачем это понимать, если процесс по гитфлоу стандартный и простой до тошноты - мердж к себе в фича бранч - резолв конфликтов - пул реквест для мерджа в дев ветку. Черипики эпизодические. Вот реально, за 14 лет использования гита практически ни разу не понадобились знания о Head, даже если они есть.
Т.е. никогда не делали git reset HEAD~1? Или никогда не сквошили коммиты через git rebase -i HEAD~3? Это тоже вроде базовые вещи, без которых никуда.
На самом деле недостаток статьи в том, что HEAD работает вполне логично и интуитивно в git, особенно если хоть немного поинтересоваться как именно гит хранит историю и коммиты.
Но плюс, что статья ведет к тому, что кто-то этим заинтересуется.
Я может избалован Visual Studio, но единственная команда, которой приходится пользоваться вручную git branch -u origin/xxx, остальное есть в графическом интерфейсе и делается быстрее через него.
PS. Хотел ответить товарищу выше, но промахнулся
Ну вы разработчик.
А в случае инфраструктурного инженера, вся автоматизация делается через консольные команды и скрипты, но там обычно используются базовые команды.
И только при больших репозиториях надо немного поискать всякие хитрости, чтобы ускорить процесс.
Я через GitExtensions работаю, в связке с KDiff3 оно весьма успешно абстрагирует всяческие ресеты и мерджи до той степени, когда ты просто фокусируешься на задаче и коде, который надо смерджить. А проблемы сквоша коммитов и раздувания истории решаются при пул реквесте выставлением галочек squash commits + delete source branch.
можно и в одной ветке работать 14 лет, это ж не показатель
Если кому-то интересно, вот пример, как выглядит имплементация самого базового функционала гита, включая HEAD, и создание коммитов.
Недавно я провела в Mastodon опрос
примерно 1700 голосов
Ничего себе там движуха...
Публикации
Как в git работает HEAD