2013-05-14 2 views
2

* это один из тех, «это хорошая идея?» вопросы, которые я не могу форматировать в SO приемлемый вопрос, но ....создание ветки только для слияния

Я по-прежнему не на 100% удобен с git, особенно слиянием с удаленными ветвями. Если что-то пойдет не так, или я просто хочу отказаться от кучи конфликтов слияния, я, как правило, стараюсь откатить слияния/коммиты. Я обнаружил, что дальше дальше по кроличьей норе. Мне интересно, было бы проще создать ветку только для того, чтобы сделать удаленное слияние, а затем локально слить ветвь temp с моей «реальной» ветвью »? Таким образом, я всегда мог развязать временную ветку, если что-то пошло не так.

UPDATE: Я специально заинтересован в том, когда мой удаленный филиал добавит кучу файлов в моем репо Например (используя пример Питера ниже):.

Я делаю это:

$ git init 
Initialized empty Git repository in /path/to/repo/.git/ 
$ touch README 
$ git add README 
$ git commit -m 'Initial commit' 
[master (root-commit) da9886d] Initial commit 
0 files changed 
create mode 100644 README 
$ touch A 
$ git add A 
$ git commit -m 'Add A' 
[master 3480a5b] Add A 
0 files changed 
create mode 100644 A 
$ git push // pushed to remote (only a single file, A) 

Затем другой разработчик делает это:

$ git clone 
$ touch B 
$ git add B 
$ git commit -m 'Add B' 
[foo 9912a23] Add B 
0 files changed 
create mode 100644 B 
$ git push // pushed to remote (now has two files A and B) 

Если бы я тогда это сделать:

$ git pull 

Я буду иметь два файла A и B. Теперь, если я хочу, чтобы «шаг назад» и отменить слияние:

$ git reset --hard [email protected]{...} 

Файл B будет по-прежнему существовать на моей машине в качестве незатронутого файла, верно? Как я могу отступить и удалить эти файлы, как если бы я никогда не делал слияние git?

Вот почему я надеялся создать отдельную ветку. Если я создаю отдельную ветку для выполнения слияния:

$ git checkout -b tempBranchForMerge 
$ git pull 

Я до сих пор в конечном итоге с файлами А и В, но они существуют только на tempBranchForMerge. Если что-то пойдет не так, я должен это сделать:

$ git checkout master 
$ git branch -d tempBranchForMerge 

правый? Это удалит файл B.

ответ

2

Это абсолютно нормально, но не нужно.

Git уже отслеживает историю перемещений ваших филиалов, с которой вы можете получить доступ с помощью git reflog. Мне особенно нравится git reflog <branch name>.

Давайте попробуем пример. Вот несколько команд, которые просто настраивают этот пример. У меня есть master и ветвь foo. Каждый из них имеет одну фиксацию. Затем я объединяю foo в master.

$ git init 
Initialized empty Git repository in /path/to/repo/.git/ 
$ touch README 
$ git add README 
$ git commit -m 'Initial commit' 
[master (root-commit) da9886d] Initial commit 
0 files changed 
create mode 100644 README 
$ touch A 
$ git add A 
$ git commit -m 'Add A' 
[master 3480a5b] Add A 
0 files changed 
create mode 100644 A 
$ git checkout -b foo HEAD~1 
Switched to a new branch 'foo' 
$ touch B 
$ git add B 
$ git commit -m 'Add B' 
[foo 9912a23] Add B 
0 files changed 
create mode 100644 B 
$ git log --decorate --graph --all --pretty=oneline --abbrev-commit 
* 9912a23 (HEAD, foo) Add B 
| * 3480a5b (master) Add A 
|/ 
* da9886d Initial commit 
$ git checkout master 
Switched to branch 'master' 
$ git merge foo 
Merge made by the 'recursive' strategy. 
0 files changed 
create mode 100644 B 
$ git log --decorate --graph --all --pretty=oneline --abbrev-commit 
* d4d06ce (HEAD, master) Merge branch 'foo' 
|\ 
| * 9912a23 (foo) Add B 
* | 3480a5b Add A 
|/ 
* da9886d Initial commit 

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

$ git reflog master 
d4d06ce [email protected]{0}: merge foo: Merge made by the 'recursive' strategy. 
3480a5b [email protected]{1}: commit: Add A 
da9886d [email protected]{2}: commit (initial): Initial commit 
$ git reset --hard [email protected]{1} 
HEAD is now at 3480a5b Add A 
$ git log --decorate --graph --all --pretty=oneline --abbrev-commit 
* 9912a23 (foo) Add B 
| * 3480a5b (HEAD, master) Add A 
|/ 
* da9886d Initial commit 
+0

Хорошие примеры. Я добавлю, что если я заранее знаю, что у меня может получиться что-то сложное, я просто пометю, где я сейчас, с помощью git tag safepoint', а затем сделаю все, что захочу. Если все отправится на юг, я могу просто «git reset - hard safepoint». Важно понимать рефлог, если вы этого не сделали, конечно. –

+0

Когда вы вернетесь к мастеру @ {1}, будет ли файл B удаляться или будет существовать, но не отслеживаться? Я предполагаю, что ваше описание также будет работать для слияния с удаленной ветвью. – tir38

+0

Он удалит файл. 'git reset --hard' переместит указатель ветки на данный аргумент и сделает рабочее дерево похожим на то, что было тогда. Существуют и другие варианты, кроме '--hard'. Для более подробного объяснения см. 'Git help reset'. –

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