Git голова отделена от мастера

1 ответ

Лучший ответ

Последняя фиксация в any ветке задается идентификатором хэша фиксации, хранящимся в имени ветки .

Вот и все — все действительно так просто. Git фиксирует ссылку только в обратном направлении , от дочернего к родительскому. Таким образом, каждое имя ветки должно хранить хэш-идентификатор своей последней фиксации.

После этого у вас, как вы сказали в заголовке, появится «отдельная ГОЛОВА». Это означает, что вы больше не находитесь ни в одной ветке . Вопрос о «последней фиксации» становится бессмысленным: указывает непосредственно на фиксацию, и эта фиксация по определению является текущей фиксацией. Вы можете проверить любой коммит, который вам нравится, например, указав необработанный хэш-идентификатор коммита, и вы по-прежнему будете находиться в отдельной HEAD, но в другой фиксации.

В результате вы находитесь в анонимной ветке (без имени), последней фиксацией которой является текущая фиксация. Создание в этот момент новой ветки, указывающей на эту фиксацию, вызывает появление этой ветки. Его последняя фиксация — это текущая фиксация, поэтому теперь последняя фиксация во вновь созданной ветке — это текущая фиксация.

Учитывая цепочку коммитов вроде:

все коммиты до находятся на , хотя также является последней фиксацией так что все коммиты до находятся на . Они находятся в обоих ветках. Коммиты и только на .

Если мы удалим name , все коммиты по-прежнему можно будет найти по имени . Git находит (все) коммиты, считывая каждый хэш-идентификатор из (всех) имен веток и других подобных имен, а затем работая в обратном направлении от этих коммитов к их родителям, родителям родителей и так далее.

Если на этом этапе вы создадите одну новую фиксацию, вы получите:

Обратите внимание, что теперь присоединен к ветви. Фиксация — последняя фиксация в этой ветке; коммиты через находятся в обеих ветвях

Если теперь отсоединить и переместить его для фиксации , вы получите:

Упражнения (выполняйте по порядку)

1. Я дам вам два необработанных хеш-идентификатора фиксации с условием, что хеш-идентификатор первой фиксации будет доступен, если начать со второй фиксации и идти назад, шаг за шагом по этим направленным назад стрелкам. Например, я мог бы дать вам хэш-идентификатор фиксации и хеш-идентификатор фиксации . Как вы можете использовать эту информацию, чтобы найти фиксацию ? (Подумайте о том, чтобы начать с фиксации и следовать за каждой стрелкой, сохраняя при этом какой-то журнал каждой посещенной фиксации.)

2. Какая следующая фиксация после фиксации ? Какая еще информация вам нужна, чтобы найти следующий коммит? Помните, что фиксация выполняется как на , так и на .

1

Community
20 Июн 2020 в 09:12

2 ответа

Лучший ответ

Следует иметь в виду: в Git ветка — это просто имя для одной фиксации . Это имеет некоторые другие последствия для того, как он себя ведет, но это все, что есть. Имена веток имеют решающее значение в Git по ряду причин; во-первых, они сохраняют коммиты в живых. Если у фиксации есть имя ветки, или она является родительской для такой фиксации, или родительской для этой фиксации …, фиксация остается в силе. В противном случае он может умереть. К счастью для вас, он не умирает быстро.

Итак, вот краткий обзор того, что вы сделали и что это значит!

Режим отдельной головы означает, что для того места, где вы находитесь, нет имени ветки: вы не находитесь «в ветке». Еще до того, как история началась, вы каким-то образом перешли в режим отдельной головы и сделали коммит. Это не незаконно, но крайне неразумно. Понятия не имею, как и почему ты сделал это с собой.

Таким образом, похоже, что у вас есть как минимум два коммита в этой родительской цепочке: отсоединенный, который вы только что создали, и коммит ветви Recycler-View, который предшествует ему.

Вы неправильно указали название ветки. Это было прямо перед вами! В следующий раз попробуйте скопировать и вставить имя ветки. Еще лучше, переключитесь на оболочку, которая дает вам автозаполнение имени ветки.

Вы правильно поняли название ветки и нажали. Но вы нажали 6dfc1a1. Вы не отправили новую фиксацию 35b478b, которая все еще отсоединена.

Нет такой ветки.

Пока такой ветки нет. Почему вы даже не спрашиваете , как называются названия веток? Эта команда (подождите) !

Довольно глупый способ узнать настоящее имя ветки, но он сработал.

Git как можно громче предупреждает вас, что вы собираетесь потерять весь именованный доступ к фиксации 35b478. Отдельно!

Хорошо, но ты это сделал. Это проблема? Нет! Не сразу. Помните, коммиты не умирают быстро. Коммит все еще существует. Просто приведи себя в равновесие, а затем скажи

Престо, твоя потерянная фиксация снова вернулась! На этот раз сделайте с ним что-нибудь разумное. Отсоединенная фиксация может в конечном итоге быть удалена, поэтому, если вы не хотите, чтобы это произошло, спасите эту фиксацию! Самый простой первый шаг — это, проверив фиксацию, присвоить ей имя ветки:

Теперь вы можете решить, что делать с сохраненной фиксацией. Я не знаю, каковы были ваши намерения, поэтому не могу вам посоветовать.

3

matt
6 Май 2021 в 01:36

В вашей командной строке показано, что вы можете создать ветку для фиксации с помощью

Здесь — это идентификатор фиксации. Это означает, что вы также можете переключиться на новую ветку, когда сделаете это, используя

Безотказная касса без филиала была бы

Вы можете увидеть фиксацию с помощью

Здесь перечислены коммиты, которые вы посетили, а не только те, которые были в вашей непосредственной истории.

Вы также можете получить его с помощью

2

Mad Physicist
6 Май 2021 в 05:46

Шаг 3

После того, как в ветку добавлен коммит , Git пытается добавить туда же . Тут, опять же, если конфликтов нет, то добавляется после и операция оказывается успешно завершённой. Если обнаружен конфликт, то Git, как и прежде, сообщит об этом и предложит с ним разобраться.

После завершения работы команды можно будет увидеть, что в ветке имеются коммиты , , , , и .

Примечание

При работе с Git находят применение и команда , и команда . Нельзя сказать, что одна из них предпочтительнее другой.

В случае использования команды вы получите коммит-слияние. В случае использования никаких дополнительных коммитов у вас не будет.

Рекомендуется использовать эти команды в различных ситуациях. Так, подходит для обновления кода локального репозитория на основе свежего кода из удалённого репозитория. Используйте команду , выполняя пулл-запросы, направленные на слияние ветки с веткой или .

Итоги

Изучив представленные в этом материале концепции, вы улучшили свои навыки владения Git и приблизились к уровню Git-эксперта. Надеемся, то, что вы тут узнали, вам пригодится. Но мир Git огромен, поэтому, освоив что-то новое, не останавливайтесь на достигнутом и двигайтесь дальше.

Примечание

Используйте команду только в своём локальном репозитории. Её применение в удалённых репозиториях может привести к огромной путанице.

Наведение порядка в истории коммитов

Предположим, вы работаете над неким фрагментом кода какого-то проекта. Вам известно, что это займёт примерно десять дней. В течение этих десяти дней другие разработчики делают коммиты в исходный репозиторий.

Рекомендуется поддерживать синхронизацию между локальным и удалённым репозиториями. Это позволяет избежать множества конфликтов, связанных со слиянием, возникающих при слишком редкой синхронизации репозиториев. Следуя этой практике, вы решаете загружать изменения из удалённого репозитория каждые два дня.

Каждый раз, когда вы загружаете код из удалённого в локальный репозиторий, в локальном репозитории создаётся новый коммит-слияние (Merge Commit). Это означает, что в вашей локальной истории коммитов будет много таких коммитов, которые могут запутать того, кто будет просматривать ваш код.

История коммитов в локальном репозитории

Как привести в порядок историю коммитов? Для решения этой задачи можно воспользоваться командой .

Команда git rebase

Рассмотрим команду на примере.

Коммиты в ветке Release и в ветке Feature

В ветке есть три коммита: , , и . Вы создали свою ветку из ветки , когда в ней был всего один коммит — . После этого вы добавили два коммита в ветку . Это — и . Ваша цель заключается в том, чтобы загрузить коммиты из ветки в свою ветку . Для того чтобы это сделать, вы собираетесь воспользоваться командой .

Будем использовать для двух рассматриваемых веток имена и .

В результате применение команды будет выглядеть так:

Особенности команды rebase

Команда используется для того, чтобы обеспечить наличие в ветке свежего кода из ветки .

При применении этой команды система пытается добавить в ветку каждый коммит, по одному, и осуществить проверку на наличие конфликтов. Если звучит это сложно — давайте рассмотрим следующий рисунок. Тут показаны внутренние механизмы команды .

Ветка Feature и три шага работы команды rebase

Сценарий №3

К коммитам, которые делают в Git, привязаны имя автора и адрес его электронной почты. Обычно эти данные указывают, выполняя первоначальную настройку Git. В результате тот, кто использует Git, может, выполняя каждый коммит, не заботиться о сведениях об его авторе.

При этом вполне возможна ситуация, когда, при работе с некоторыми проектами, будет нужно пользоваться сведениями об авторе, например — адресом электронной почты, отличающимися от основных. Для подобного проекта нужно указать адрес электронной почты, воспользовавшись такой командой:

Предположим, вы забыли выполнить такую настройку и уже сделали первый коммит. Исправить положение может уже знакомая нам команда . С её помощью можно изменить сведения об авторе предыдущего коммита:

Ограничение вывода

В дополнение к опциям форматирования вывода, команда принимает несколько опций для ограничения вывода – опций, с помощью которых можно увидеть определенное подмножество коммитов. Вы уже видели одну из таких опций – это опция , которая показывает только последние два коммита. В действительности вы можете использовать , где n – это любое натуральное число, представляющее собой n последних коммитов. На практике вы не будете часто использовать эту опцию, потому что Git по умолчанию использует постраничный вывод и вы будете видеть только одну страницу за раз.

Однако, опции для ограничения вывода по времени, такие как и , очень удобны. Например, следующая команда покажет список коммитов, сделанных за последние две недели:

Это команда работает с большим количеством форматов – вы можете указать определенную дату вида 2008-01-15 или же относительную дату, например 2 years 1 day 3 minutes ago.

Также вы можете фильтровать список коммитов по заданным параметрам. Опция дает возможность фильтровать по автору коммита, а опция искать по ключевым словам в сообщении коммита.

Примечание

Допускается указывать несколько параметров и для поиска, которые позволят найти коммиты, соответствующие любому указанному и любому указанному шаблону ; однако, применение опции заставит искать коммиты соответствующие всем указанным шаблонам .

Следующим действительно полезным фильтром является опция , которая принимает аргумент в виде строки и показывает только те коммиты, в которых изменение в коде повлекло за собой добавление или удаление этой строки. Например, если вы хотите найти последний коммит, который добавил или удалил вызов определенной функции, вы можете запустить команду:

Последней полезной опцией, которую принимает команда как фильтр, является путь. Если вы укажете каталог или имя файла, вы ограничите вывод только теми коммитами, в которых были изменения этих файлов. Эта опция всегда указывается последней после двойного тире (—), чтобы отделить пути от опций:

В таблице 3 вы можете увидеть эти и другие распространенные опции.

Таблица 3. Опции для ограничения вывода команды

Опция	Описание
	Показывает только последние n коммитов.
,	Показывает только те коммиты, которые были сделаны после указанной даты.
,	Показывает только те коммиты, которые были сделаны до указанной даты.
	Показывает только те коммиты, в которых запись автор совпадает с указанной строкой.
	Показывает только те коммиты, в которых запись коммитер совпадает с указанной строкой.
	Показывает только коммиты, сообщение которых содержит указанную строку.
	Показывает только коммиты, в которых изменение в коде повлекло за собой добавление или удаление указанной строки.

Например, если вы хотите увидеть, в каких коммитах произошли изменения в тестовых файлах в исходном коде Git в октябре 2008 года, автором которых был Junio Hamano, и которые не были коммитами слияния, вы можете запустить следующую команду:

Из почти 40 000 коммитов в истории исходного кода Git, эта команда показывает только 6, которые соответствуют этим критериям.

Подсказка

Предотвращение отображения коммитов слияния

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