Чому git встановив нас (без гілки)?


75

Сьогодні вранці ми витягуємо з нашого репо, і git поставив нас (немає гілки).

Я цього не розумію, чому так сталося? І як із цього вийти, не втрачаючи наших змін?

Відповіді:


102

"На даний момент не на жодній гілці" означає, що у вас від'єднана голова , тобто ваш вказівник HEAD безпосередньо посилається на коміт, а не символічно вказує на назву гілки.

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

Кажуть, що ви можете втратити свої зміни, коли перемикаєтеся з від'єднаної ГОЛОВИ на якусь гілку, але рефлог завжди буде відстежувати, куди рухалася ГОЛОВА. Насправді, Git 1.7.5 попереджатиме вас, коли перехід з від'єднаної HEAD втратить коміти. Єдиний раз, коли ви дійсно можете втратити роботу, це коли у вас є незафіксовані зміни, які ви, можливо, захочете здійснити або сховати.

Простий спосіб дізнатись, що сталося, - git reflogабо git log -g --decorateотримати більш детальний перелік. --decorateВаріант буде маркувати кожен SHA1 з іменами всіх гілок, точка на ній. Якщо SHA1 вашого поточного HEAD точно такий самий, як і master, то вам не потрібно нічого робити, крім git checkout masterяк повернутись на правильний шлях. В іншому випадку перевірте, чи вказує на SHA1 якась інша гілка. Якщо ні, то, можливо, ви захочете створити гілку, на якій би можна було повіситись.

Ще однією гарною командою є те git branch -av, що аналогічним чином буде перераховано всі гілки та те, на що вони вказують, так що ви зможете побачити, якою (no branch)має бути ваша насправді.


Хоча багато людей кажуть, що це git reflogпрацює для них, мені це нічого не повертає. git branch -avповертає всі віддалені гілки та те, на що вони вказують, але я не знаю, як це стосується моєї локальної речі. Де я? В якій гілці та в якому комітеті я перебуваю? Це те, що я рано хочу знати.
дуду,

32

Важко сказати без додаткових деталей.

git pullотримує зміни з віддаленого сховища, а потім робить злиття. Його можна налаштувати на перебазування замість злиття (або за допомогою git pull --rebase, або за допомогою налаштування справжнього значення для branch.<branch_name>.rebaseгілки, в яку ви тягнете).

Якщо ви починали роботу з гілки, будь-яке злиття типу завжди залишатиме вас на цій гілці. З іншого боку, команда rebase завжди працює, використовуючи тимчасово від'єднану HEAD (вона ж "немає гілки"). Якщо ви залишилися в такому стані під час витягування типу rebase, то це пов’язано з тим, що частина перетягування частини витягування зіткнулася з конфліктами, і він чекає, поки ви їх вирішите та використаєте rebase --continue(або --skip, або --abort).

За замовчуванням рефлог зберігає кожне оновлення HEAD (може бути і одне для кожної гілки). Ви можете переглянути перезапис за допомогою git reflog show(або git log -gдля більш детального перегляду). Це може допомогти вам визначити, як ви потрапили в цей стан.

Якщо ви перебуваєте в середині перебази (у вас є .git/rebase-applyкаталог), то він, ймовірно, зупинився, щоб дозволити вам вирішити деякі конфлікти. Використовуйте git statusдля перевірки на наявність “нез’єднаних” записів. Будь-які такі записи повинні мати вбудовані у файли маркери конфліктів (припускаючи, що це текстові файли). Вам слід відредагувати їх, щоб вирішити конфлікт (-и), і вони позначать їх як об’єднані, запустивши git addна них. Потім запустіть, git rebase --continueщоб продовжити перебазування. Ви можете зіткнутися з більшою кількістю конфліктів, які слід розглядати подібним чином (редагувати, додавати, продовжувати). Якщо ви вирішите, що вам більше не потрібен певний коміт, ви можете пропустити його за допомогою git rebase --skip. Ви можете перервати всю базу даних за допомогоюgit rebase --abort. Усі ці команди перебазування перераховані в повідомленні про помилку, коли перебазування зупиняється через будь-який конфлікт. Після того, як усі очікувані коміти будуть застосовані (або пропущені), ваша початкова гілка буде оновлена ​​до остаточного нового коміту, і ваша HEAD буде знову приєднана до неї (якщо ви скасуєте, ваша HEAD буде повторно приєднана без оновлення гілки).

Якщо ваша від'єднана HEAD не пов'язана з конфліктами, що виникли в середині перебази, то ваша HEAD була від'єднана в якийсь момент до витягування. Вам потрібно буде оцінити поточний стан дерева, щоб вирішити, що ви хочете зробити. Ви можете скористатися git show-branch --current --allабо git log --graph --oneline --decorate --allграфічним інструментом, як, наприклад, gitkщоб дізнатись, як ваша поточна (відокремлена) HEAD співвідноситься з іншими гілками. Якщо ви вирішите, що хочете зберегти вміст вашої ГОЛОВИ, тоді ви можете зробити для них нову гілку git branch new_branch_name. Якщо ви хочете перезаписати існуючу гілку, використовуйте git branch --force existing_branch_name. Потім використовуйте git checkout branch_nameдля повторного приєднання HEAD вашого сховища до гілки.


2
Приємна порада про наявність .git/rebase-applyпідказки.
millhouse

2

Зверніть увагу, що у випадку " git pull --rebase" запуску під час HEADвід'єднання, Git спробував знайти вищу гілку від'єднаного HEAD(яке за визначенням не існує) і видав непотрібні повідомлення про помилки.

Це більше не стосується Git1.8.0.1 (26 листопада 2012 р.)

Перегляньте цей коміт .

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.