2012-04-26 7 views
3

Я объединил ветвь dev (с постоянными, иногда неустойчивыми изменениями) к нашей главной ветке (где мы храним выпущенный, стабильный код). Я хочу восстановить главную ветвь до состояния, которое было раньше, как никогда не произошло слияние с веткой dev (и что когда в будущем мы объединим ветвь dev, все изменения, которые мы отбросим, ​​теперь будут объединены «снова»).Вернуть нажатую ветвь в конкретную фиксацию

Это текущий статус ведущей ветви, и я хочу, чтобы в HEAD был установлен «commit-1.1.2» commit/tag.

status of the master branch

Я пробовал:

$ git revert -n professional-1.1.2..HEAD 
fatal: Commit 9167e846a387c793edbc089c7ab6bd9eb8260456 is a merge but no -m option was given. 
$ git revert -n -m 1 professional-1.1.2..HEAD 
fatal: Mainline was specified but commit 380169097f35d07466640bc0db1b639278cd25fa is not a merge. 
$ git revert -n -m 2 professional-1.1.2..HEAD 
fatal: Mainline was specified but commit 380169097f35d07466640bc0db1b639278cd25fa is not a merge. 

После небольшого исследования я думаю, что лучший вариант, это сделать git reset --hard professional-1.1.2 и git push --force как ответ на Git: How to ignore fast forward and revert origin [branch] to earlier commit? или reverting push'd git commit. Другие разработчики находятся в одном офисе, и они никогда не должны совершать что-либо, чтобы справиться с ними (как и я, но ... да, у нас нет разрешений на каждую ветку), поэтому не стоит говорить им и делать какие-либо необходимое действие.

Таким образом, в конце концов, вопрос: git revert something или git reset --hard <TAG> & & git push --force? Если git revert, какую команду я должен использовать?

+1

Ответ дается Jefromi в http://stackoverflow.com/questions/3556501/git-how -to-reset-after-merging может вам помочь. – vpatil

+0

@vpatil, так лучше использовать 'git reset --hard', чем' git revert' в моем случае? –

+1

Да, я так думаю, потому что revert создает новую фиксацию, которая отменяет последнее коммит. Я бы определенно предложил использовать сброс. – vpatil

ответ

6

Параметр -m number указывает, из какого родителя вы хотите вернуться (поскольку слияние имеет несколько родителей).

Так что вы хотите git revert -m 1 HEAD или git revert -m 1 SHA_OF_MERGE_COMMIT (предполагая, что вы сделали git checkout master; git merge devel;)

+0

, но я не хочу возвращать только фиксацию слияния, но все коммиты, которые пришли с этим слиянием.Btw I dit 'git checkout master; git pull origin develop'. –

+2

@ CarlosCampderrós. Как вы думаете, что происходит слияние? Да, это вернет слияние, что означает: он удалит все изменения, которые вы объединили в свою ветку. –

+0

ok У меня просто был неправильный синтаксис отмены (поэтому он не работал, когда я сначала пытался (как вы можете видеть в вопросе)), и я выбрал неправильного родителя, когда я использовал ваш ответ. Теперь ... если через 2 месяца я снова объединить ветвь dev, все коммиты, которые я верну, будут слиты? Или только будут объединены изменения после слияния, которое я сейчас возвращаю? –

6

Если вы просто хотите, чтобы состояние master точно так же, как professional-1.1.2, избегая переписывания истории и сил толкания, вы можете просто создать новая фиксация поверх мастера, которая представляет одно и то же состояние проекта, как professional-1.1.2. Вы можете сделать это с помощью следующих шагов:

# Check that "git status" is clean, since the steps that follow will throw 
# way uncommitted changes: 
git status 

# Set the index (staging area) to be as it was at professional-1.1.2: 
git read-tree professional-1.1.2 

# Create a commit based on that index: 
git commit -m "Reverting to the state at professional-1.1.2" 

# Your working tree will still be as it was when you started, so 
# you'll want to reset that to the new commit: 
git reset --hard 

В качестве альтернативы, вы можете следовать шаги, предложенные в this answer by Charles Bailey, который выполняет то же самое, но немного более запутанным, я думаю, что (несмотря на то, что шаги, которые я» Вы предложили включить команду «сантехника» git read-tree).

+0

Используя это (сделав новый коммит со статусом профессионала-1.1.2 и нажав его), это позволит снова слияние ветви dev снова привести снова к изменениям, которые теперь я «возвращаю»? –

+0

Если коммит, который я предложил ввести, заканчивается с именем объекта 'f414f31', я думаю, что вы можете сделать работу будущего слияния, выполнив' git revert f414f31' перед 'git merge dev'. (Я думаю, что принцип такой же, как с [reverting-a-reverted-merge] (http://schacon.github.com/git/howto/revert-a-faulty-merge.txt).) –

+0

После прочтения http://code.google.com/p/git-core/source/browse/Documentation/howto/revert-a-faulty-merge.txt Я думаю, что вы правы @MarkLongair. Это сложнее и подвержено ошибкам (потому что, возможно, перед выполнением 'git merge dev' мы забываем о возврате возврата. Поскольку репо является закрытым, а среда контролируется, я думаю, что я перейду с' git reset - hard' и 'git push -force'. –

2

Если вы смельчак (извлечение из вышестоящего перебазирования может быть необходим для всех остальных коммиттеров)

git checkout yourbranch 
git reset HEAD <commit-hash> 
git push origin yourbranch -f