2012-04-24 2 views
8
#lets get the latest 
git pull 

#lets switch to branch and do some work 
git checkout -b makeSomeBugs 

#do the work commit 
git add . 
git commit -am "introducing some bugs" 

#push this for my lazy remote friend to see 
git push origin makeSomeBugs 

#uh .. changes on master 
git pull origin master 

#do some work.. 
git commit -am "introducing some more bugs" 
git push origin makeSomeBugs 

#lets switch back to master 
git checkout master 
git pull 

#work is done, lets merge 
git merge --no-ff makeSomeBugs 
git push origin 

#and remove the branch to never ever see it again 
git push origin :makeSomeBugs 
git branch -d makeSomeBugs 

Различные источники блога (но они довольно старые) говорят, что ветвление, как это в ртутный не идти, особенно с постоянным удалением ветви ...Git и Mercurial: что было бы эквивалентом рабочего процесса Git в Mercurial?

+0

Я пробовал и еще не нашел способ имитировать рабочий процесс ветки git в mercurial. Регулярная ветка неуверенно не работает, потому что вы не можете удалить их (только закрывайте их, но это означает, что имя ветви берется навсегда). Закладки должны быть похожи на ветки git, но они, похоже, действительно не работают, как они, по крайней мере для меня. – ryanzec

+1

@ryanzec, как вы делали закладки? –

ответ

8

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

# lets get the latest 
# git pull 

hg pull 

# lets switch to branch and do some work 
# git checkout -b makeSomeBugs 

hg bookmark makeSomeBugs 

# do the work commit 
# git add . 
# git commit -am "introducing some bugs" 

hg commit -m "introducing some bugs" 

# push this for my lazy remote friend to see 
# git push origin makeSomeBugs 

hg push -B makeSomeBugs 

# uh .. changes on master 
# git pull origin master 

hg pull 
hg merge 

# do some work.. 
# git commit -am "introducing some more bugs" 
# git push origin makeSomeBugs 

hg commit -m "introducing some more bugs" 
hg push -B makeSomeBugs 

# lets switch back to master 
# git checkout master 
# git pull 

hg pull 
hg update -C <name of master rev> 

# work is done, lets merge 
# git merge --no-ff makeSomeBugs 
# git push origin 

hg merge makeSomeBugs 
hg push 

# and remove the branch to never ever see it again 
# (I assume you mean the label not the changesets) 
# git push origin :makeSomeBugs 
# git branch -d makeSomeBugs 

hg bookmark -d makeSomeBugs 
hg push -B makeSomeBugs 

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

Существует также вопрос о том, что вы используете для определения «главной» головы. Если на нем была закладка уже на сервере (например, master), первая строка станет hg pull -B master, первое слияние hg merge master и обновление hg update -C master. После того, как вы вытащили закладку, в первый раз, когда любые последующие вытаскивания или нажатия будут обновлять ее, без необходимости явно упоминать об этом.

+0

Итак, вопрос в том, может ли в истории увидеть, что изменения, сделанные в makeSomeBugs, когда они объединены с дефолтом и нажаты на исход, по-прежнему видны как изменения в makeSomeBugs? Например. могу ли я отслеживать, что comit X и совершить Y были сделаны в makeSomeBugs после слияния? – gerasalus

+2

@gerasalus: Нет, точно так же, как ветви Гита, закладки не постоянны. Именованные ветви являются постоянными ярлыками, и у них нет эквивалента Git. 'default' относится к по умолчанию * named * branch. Это не то же самое, что «мастер». –

+3

@PaulS: теперь вам больше не нужно включать расширение закладок, поскольку теперь оно стало основной функцией Mercurial. –

2

Это почти то же самое, за исключением того, что с Mercurial вы вообще не потрудились называть свой прогресс вообще и просто использовать анонимную ветку.

Я дам, что раковину на мгновение ...

В отличии от мерзавца, Mercurial не «забывает», если ревизию нет названия филиала или закладок, связанного с ним, так что нет никакой необходимости назвав его, а затем удалив его. После этого, он выглядит довольно стандартный рабочий процесс:

#lets get the latest 
hg pull 

#lets update to the latest and do some work 
hg update 

#do the work commit 
hg commit -Am "introducing some bugs" 

#serve this for my lazy remote friend to see 
hg serve 

#uh .. remote changes 
hg pull 

#do some work.. 
hg commit -Am "introducing some more bugs" 

#lets pull in the latest 
hg pull 

#work is done, lets merge 
hg merge 
hg push 

При желании вы можете использовать закладки, если вы действительно хотите, чтобы явно отслеживать анонимные головы; при запуске (после hg update), маркировать текущий набор изменений с помощью:

hg bookmark makeSomeBugs 

И когда вы сделали (после hg merge), удалите закладку с помощью:

hg bookmark -d makeSomeBugs 

Вы также можете нажать закладку ради вашего друга, но ... meh.

+0

Вы отправляете по умолчанию, я отправляюсь в филиал. Это не одно и то же. Поскольку я могу создать другую ветку от мастера и делать любые другие вещи, не связанные с первым. – gerasalus

+2

Нет, вы совершаете новую анонимную ветку, необязательно с закладкой. Ветвление происходит всякий раз, когда линия коммитов расходится. Если вы хотите совершить что-то еще, кроме имени 'default', вам нужно сделать еще одну ветку с именем *. Вы попадаете в культурную ловушку здесь: использование анонимных ветвей распространено в Mercurial, в Git это практически невозможно. Именованные филиалы являются постоянными и должны быть установлены заранее; если вы хотите отслеживать эту анонимную ветку, вы используете закладку. –

+0

В Mercurial названные ветви являются постоянными и обычно используются для отслеживания релизов. Вы также можете использовать их для отслеживания функций, но обычно функция работы выполняется в анонимных ветвях. Закладки могут быть использованы для отслеживания работы анонимных ветвей. Это полезно, если вы работаете над несколькими вещами сразу или код должен быть общим до объединения его обратно. –

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