git: ветвление удалило некоторые коммиты - PullRequest
Новая
       38

git: ветвление удалило некоторые коммиты

2 голосов
/ 06 июля 2010

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

Я хотел перенести спекулятивное изменение (сделанное на a_file) в новую ветку и продолжить работу с основной веткой без него.

На мастере с a_file и b_file грязно Я сделал: 

git checkout -b saved_feature

git commit a_file -m "Putting this modification on a different branch"

git checkout master

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

Я все еще был на ветке saved_feature, поэтому я подумал, что смогу: 

git stash save

git checkout master

Пока все хорошо 

git stash pop

В этот момент я получаю сообщение о том, что тайник не может быть объединен.

Я проверяю журнал - по какой-то причине существует около 6 дней коммитов, которые были изначально зафиксированы в ветке master, но которых не было в журнале . Эти коммиты были только в новой ветке, которую я создал (я проверил, не передал ли я их другой ветке).

После изучения журнала ветки saved_feature я вижу, что все они есть.

Что случилось?

Я в следующий раз попробовал master: 

git merge saved_feature

Но опция ускоренной пересылки не удалась с кучей конфликтов.

Я также использую git-svn для отправки изменений во внешний репозиторий, так что master снова я сделал: 

git svn rebase

Это восстановило некоторые из ранее выдвинутых коммитов из SVN.

Затем я выбрал остальные самые последние коммиты из ветки saved_feature, Затем я сделал git stash pop, исправил конфликты, которые должны были быть автоматически объединены, но не были, и, наконец, мой master был в том состоянии, в котором он был изначально.

Может ли кто-нибудь указать в этом печальном рассказе, где моя умственная модель и мерзавец расстались и как мне избежать повторения подобных беспорядков?

1 Ответ

3 голосов
/ 06 июля 2010

Вы, вероятно, работали в эти последние 6 дней на отдельном ГОЛОВЕ от предка главного ГОЛОВА.
(спасибо Крис Джонсен за предложение, что последняя часть: это объясняет потенциально все)

Предположим, у вас есть: 

x--x--x--x <- master
      ^
      |
      T1 (tag)

Если вы сделаете 'git checkout T1', чтобы увидеть содержимое T1, boom: отсоединен HEAD прямо там.
Если вы сделаете некоторые исправления из T1, вы получите 

x--x--x--x <- master
      ^\
      | -y--y--y--y--y--y <- detached HEAD (a dirty, b dirty)
      |
     T1(tag)

Теперь git checkout -b saved_feature в этот момент создаст ветку с последними коммитами за 6 дней: 

x--x--x--x <- master
      ^\
      | -y--y--y--y--y--y--a <- saved_feature (a committed, b dirty)
      |
     T1(tag)

, но извлечение до master не является тривиальным для файла b.
И слияние с master до saved_feature также не будет тривиальным (конечно, не ускоренным)

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

...