Недавно впервые создал дополнительную ветку. Сделал в ней 8 коммитов и объединил с мастером (master). Сначала, как обычно, нажал куда-то не туда. Произошло что-то непонятное и новые коммиты пропали. После переоткрытия проекта всё вернулось как было. Со второго раза объединение прошло успешно и история стала выглядеть вот так:
А как теперь узнать, какие коммиты в какой ветке были сделаны? Или нельзя так? Оно тупо всё в мастер переносится?
Я не могу скопировать хэш коммита и не могу смотреть информацию. Элементы списка тупо не выделяются и даблклик не делается.
Ну всегда ж есть git log или другой нормальный GUI )
Reflogs older than 90 days are pruned by git-gc, so if the commit’s too old, you won’t find it.
А правда, что рефлог только 90 дней хранится?
Наверно да, почему б этому не быть правдой?
И только локально.
То есть
после 90 дней (или после скачивания проекта) это сделать будет невозможно? Или оно только за последние 90 дней хранит?
А зачем это узнавать?
В каких ветках какие коммиты и так видно.
Ну и если над проектом не один человек работает, то часто используются пул реквесты и там это есть.
Чаще полезнее узнавать в каком коммите были сделаны какие-то изменения: git blame.
Где? 
Ну на скрине - все в обоих )
Ну этож после слияния. А изначально как было - не сохраняется?
А смысл от этого знания? После слияния часто и ветку удаляют.
Ну как? Чтобы видеть весь процесс разработки от и до. Было бы прикольно. А при слиянии чтобы новый коммит создавался типа branch merging to Master, а та ветка пусть бы так и оставалась 
Так было бы намного проще что-то найти в истории (особенно когда проект большой).
Тогда получается, что и над названиями веток можно особо не париться, если оно не сохраняется.
Важно то, что сейчас в ветках.
Обычно так и есть если не через rebase сливать.
Я бы не сказал История тоже важна. А то получается, что в итоге всё в одной куче
Ну так истории изменений кода обычно хватает )
Да, но когда захочется вернуться на момент создания какой-то фичи, с сохранёнными ветками это было бы удобнее сделать. Потому что было бы наглядно видно, где какая фича была начата и где она была закончена (и там же слита в master).
При этом, заодно, в мастере хранились бы только рабочие коммиты, а не весь промежуточный мусор процесса разработки.
https://git-scm.com/book/ru/v2/Ветвление-в-Git-Перебазирование
Читать о различиях merge (с и без fast-forward) и rebase.
Ок, спасибо. Будем читать.
Чёт я не очень понял.
Тем не менее есть и другой способ: вы можете взять те изменения, что были представлены в
C4, и применить их поверхC3. В Git это называется перебазированием . С помощью командыrebaseвы можете взять все коммиты из одной ветки и в том же порядке применить их к другой ветке.
В данном примере переключимся на веткуexperimentи перебазируем её относительно веткиmasterследующим образом:
$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command
Это работает следующим образом: берётся общий родительский снимок двух веток (текущей, и той, поверх которой вы выполняете перебазирование), определяется дельта каждого коммита текущей ветки и сохраняется во временный файл, текущая ветка устанавливается на последний коммит ветки, поверх которой вы выполняете перебазирование, а затем по очереди применяются дельты из временных файлов.
То есть, если при merge возникли конфликты, нам дают выбрать, какой код оставить? А при rebase все коммиты сваливаются “как есть” в одну ветку? Так ведь трешовое месиво получится