2013-06-14 4 views
1

У меня есть следующая недавняя история в моем git repo.Git перематывать ветвь мастера на конкретную фиксацию в истории мастера

* 7661a06 (HEAD, origin/devConsolidate, devConsolidate) Fix seg fault; OCBA intermediary compares by value() now also 
| * 0bbe038 (origin/master, master) Flawed work no seedShift 
|/ 
* 62fe9db Turn on OCBA_DEBUG; nan/inf values in OCBA prior to crash 
* 71298c8 Turn on OCBA (non-intermediary); seg fault occurs 
* 3693904 No OpenMP, no OCBA; no memory leaks on valgrind 
* 9d5686c Disable OpenMP threads 
* 80bbc3b Debug (-O0) build now throws exception also 
* e148013 Post convert simulation4_NEJMdisutilities [] to at() 
* 66cfba9 Post convert OCBA [] to at() 
* 32db3be Pre convert OCBA [] to at() 
* 4a9f25b Prep for debugging 
* 907e88b Found error (vector out of bounds); need to fix from here 
* ca6c639 Implement elapsed, iteration, and max time in OCBA 
* db68c15 Fix SEG FAULT; OCBA now working (with intermediary) 
* f1c6f05 GA now uses OCBA; GA/OCBA params from config file; produces SEG FAULT 
| * 3b16dcf (origin/genCRNgraph, genCRNgraph) Generate QALYs test and control independent-sampling 
|/ 
* 001eff2 Merge branch 'OCBAdev' 

Все коммиты после (потомков) f1c6f05 было сделано для отладки проблемы. Оглядываясь назад, я должен был создать отдельный ветвь для этой отладки, но я сделал все это в master. Теперь, в фиксации 7661a06, я исправил ошибку.

Я хочу переместить (перемотать?) Ветку (или указатель) master так, чтобы она была расположена при фиксации f1c6f05. После этого я могу создать патч от разницы между коммитами 7661a06 и 62fe9db и применить его к f1c6f05. В результате, часть моего журнала мерзавца должен выглядеть следующим образом:

* 7661a06 (origin/devConsolidate, devConsolidate) Fix seg fault; OCBA intermediary compares by value() now also 
| * 0bbe038 Flawed work no seedShift 
|/ 
* 62fe9db Turn on OCBA_DEBUG; nan/inf values in OCBA prior to crash 
      . 
      .   
      . 
* db68c15 Fix SEG FAULT; OCBA now working (with intermediary) 
| * <HASH> (HEAD, origin/master, master) Fix problem and rewind master 
|/ 
* f1c6f05 GA now uses OCBA; GA/OCBA params from config file; produces SEG FAULT 
| * 3b16dcf (origin/genCRNgraph, genCRNgraph) Generate QALYs test and control independent-sampling 
|/ 
* 001eff2 Merge branch 'OCBAdev' 

Какие команды будут использовать для достижения всего этого? В частности, как бы я: (1) переместить мастер, (2) создать патч и (3) применить патч?

ответ

4

Поскольку вы уже толкнул master к origin (origin/master находится в 0bbe038), это вызовет проблемы для тех, кто имеет уже вытащил или потянул с origin с вашего толчка. Таким образом, вам может потребоваться общение и координация с другими, что происходит, чтобы они могли при необходимости корректировать.

Имея это в виду, однако, вот как бы это сделать:

1) Мастер перемещения назад f1c6f05:

git checkout master 
git reset --hard f1c6f05 
git push -f origin master 

2 + 3) Вместо того чтобы создавать и применять патч, предполагая 7661a06 является единственным уместным совершить для исправления, вы можете просто сделать это:

git checkout -b bug-fix-branch master 
git cherry-pick 7661a06 

возможно, вы можете получить некоторые незначительные конфликты, в зависимости от точности ш что все «отладочные» коммиты действительно делали, и касались ли они чего-нибудь рядом с тем, что произошло с изменением 7661a06, но это должно быть довольно легко исправить. Как только это будет сделано, сделать это, чтобы объединить эти изменения обратно в мастер:

git checkout master 
git merge bug-fix-branch 
git branch -d bug-fix-branch # optional, maybe not desired 
git push origin master 

На данный момент, все еще нужно будет принести/тянуть новый master ветвь, и перезапустить любую работу, они в ожидании.

Если нарушение других неприемлемо, вы можете сделать это в качестве альтернативы:

git checkout master 
git revert f1c6f05..62fe9db 
git push master 

Это создаст новые коммиты на мастере, которые отменяют действие все эти «отлаживать» совершает, но на самом деле не удалить их из истории. Таким образом, конечный контент вашего рабочего каталога должен выглядеть одинаково, но история будет выглядеть совсем по-другому.В этом случае не должно быть никаких сбоев для других, поэтому в зависимости от вашей среды/рабочего процесса это, вероятно, лучший вариант, но он документирует для потомков ошибки, которые могут привести к путанице/проблемам в будущем, если вам когда-нибудь понадобится использовать git bisect для отслеживания новых ошибок или чего-то еще ...

+0

О, я забыл упомянуть, что это частное репо. Других разработчиков нет. – synaptik

+0

Итак, в этом случае 'origin' является либо« резервным »репо, либо просто другой копией репо на другой системе (возможно, настольный компьютер или ноутбук)? В любом случае, проблема с использованием 'git reset' и' git push -f' должна быть довольно минимальной. Тем не менее, вы можете столкнуться с дополнительным ударом на дороге, если «origin» не является голой репо - вам может потребоваться убедиться, что «master» * не * проверен там до нажатия. – twalberg

+0

'origin' - это просто резервная копия, которую я храню на частном репозитории github. – synaptik

0
git checkout master 
git reset --hard f1c6f05 
git rebase --onto master 62fe9db devConsolidate 

Если вы счастливы с историей devConsolidate после этого:

git checkout master 
git merge devConsolidate 
+0

Удалит ли это мои поручения? (Я не хочу этого делать.) – synaptik

+1

Это действительно сложно * удалить * совершает с Git. Все эти коммиты по-прежнему будут доступны через их хеши (пока они не будут собраны мусором, которые не будут происходить в течение как минимум 30 дней). История перезаписи ('git reset' и' git rebase' в этом случае) всегда создает новую версию истории и перемещает указатель (ветку) в новую. Если вам нужна ссылка на то, где вы были до 'git reset' или' git rebase', просто откройте ветку: 'git branch foo'. Если вы забудете это сделать, вы можете следить за историей филиалов с помощью 'git reflog'. –

Смежные вопросы