2009-09-10 21 views
46

Geçtiğimiz günlerde SVN'den Mercurial'e geçtim. Şimdi, diğer geliştiricilerin depoda ne olduğunu anlamalarını umarak, iyi uygulamalara göre Mercurial'da amaçlanan dallanma iş akışımı nasıl gerçekleştireceğimi merak ediyorum. Serbest bırakma dallarını Mercurial'da yönetme

  1. Genellikle Mevcut yayın serisinde işin gerçekleştirildiği bir gövde/varsayılan dalı vardır:

    Bu

    iş akışıdır. Diyelim ki bu 1.x. Aynı zamanda bir sonraki büyük sürüm üzerinde çalışmak için bir şube 2.x kullanıyorum. Bu daldaki değişiklikler radikal olabilir, bu nedenle gövde/varsayılan/1.x dalı ile birleşmek burada bir anlam ifade etmemektedir.
    • Bir süre çalıştıktan sonra 2.x bitmiş olabilir ve sürüm 2.0 serbest bırakılabilir. Şimdi 2.x şubesinin yeni varsayılan/trunk şubesi olmasını ve mevcut varsayılan/trunk'un 1.x şubesi olmasını istiyorum.
    • Bu işlemi tekrarlayarak yeni bir 3.x dalı olabilir. Daha önce olduğu gibi, 3.0 serbest bırakılırsa, 3.x yeni varsayılan şube olurken, o anda geçerli varsayılan değer 2.x dalı olacaktır (tekrar).

Sorum bu iş akışı iyi bir (Ben temelde yanlış değil sanırım) olup olmadığı değil olduğunu. Benim sorularım, bunu Mercurial'da fark ettiğim yolun iyi bir uygulama olarak mı yoksa daha iyi fırsatlar mı olduğu şeklinde yorumlanabilir.

$ hg init 
$ echo "hello world" > file1.txt 
$ hg ci -A -m "Initial commit of 1.x code" 

: Yani burada

ben ...

Mevcut yayın serisi 1.x kodunu tutan tek bir dalı olan bir depodan başlayarak Mercurial şube yönetmek için plan nasıl salma 2.x üzerinde çalışmaya başlayın:

arada
$ hg branch 2.x 
$ hg ci -m "Create new branch for 2.x development" 
$ echo "Big new feature for 2.x" > file2.txt 
$ hg ci -A -m "Add big new feature" 

, güncel sürüm serisinin bazı işler yapmak (1.x):

$ hg up default 
$ echo "Minor adjustments specific for 1.x" > file3.txt 
$ hg ci -A -m "Minor adjustments" 

Bir süre sonra 2.0 sürümü hazır, yippee! varsayılan şube varsayılan için 2.x 1.xve olun:

$ hg up default 
$ hg branch 1.x 
$ hg ci -m "Make default branch to 1.x branch" 
$ hg up 2.x 
$ hg ci --close-branch -m "Close branch 2.x" 
$ hg branch --force default 
$ hg ci -m "Make former 2.x branch to new default" 

Şimdi yeni bir şube 3.x ve içindeki çalışma oluşturmak, ayrıca varsayılan üzerinde çalışmak . Bir süre 3,0 hazırdır ve sonrasında Yine, zaman şube isimlerini yönetmek için tekrar var:

$ hg up default 
$ hg branch --force 2.x # (reuse previously closed 2.x branch name) 
$ hg ci -m "Make default branch to 2.x branch" 
$ hg up 3.x 
$ hg ci --close-branch -m "Close branch 3.x" 
$ hg branch --force default 
$ hg ci -m "Make former 3.x branch to new default" 

şimdi repo gibi görünebilir (kafaları 'o'):

o Branch default (3.x) 
| 
| o Branch 2.x 
\| 
    | o Branch 1.x 
    \| 
    | 
    . 

ana nokta şube adlarını yeniden kullanıp varsayılan numaralı şubeyle hokkabazlık yapmak iyi bir uygulamadır.

Bu soru için bir çok metin - üzgünüm - ama ne yaptığım konusunda net olmak istedim.

+0

[Mercurial wiki] (http://www.mercurial-scm.org/wiki/StandardBranching) bu konu hakkında iyi bir tanıtım sağlar. – xyres

cevap

47

İşte öyle yapardım:

default sizin "ana hat" şube olun. Bu şubenin ucu, kodunuzun "şu anda herkese açık" sürümüdür. Kritik hata düzeltmeleri doğrudan bu şubeye işlenebilir ve geliştirme dallarına birleştirilebilir.

Sürüm 2.0 üzerinde çalışmaya başlamak için 2.0-dev dalını yapın. Bu şube için 2.0 için değişiklikleri yapın ve ana çizgiden (default) kritik hata düzeltmelerini birleştirin. 2.0 ile işiniz bittiğinde, 2.0-dev'u default ile birleştirin ve sonucu 2.0 olarak etiketleyin.

İşleri bu şekilde yapmak, şube adlarını düzenleme konusunda endişelenmenize gerek olmadığı gibi, kritik hata düzeltmelerini de ana hatlarıyla geliştirme hatlarına kolayca birleştirebilirsiniz.

Aynı zamanda birden çok sürümde aynı anda çalışırken ölçeklendirir (2.1 ve 3.0). 3.0 akımını korumak için 2.1 değişikliklerini periyodik olarak 3.0'a birleştirebilirsiniz.

Böyle bir grafikle birlikte bitireceğiz:

$ hg glog -l 1000 
@  changeset: 25:efc0096f47c0 tip 
|  summary: Added tag 3.0 for changeset d1a7fc3d7d77 
| 
o  changeset: 24:d1a7fc3d7d77 3.0 
|\  summary: Merge in the redesign changes. 
| | 
| o  changeset: 23:b5b69d24c8f7 3.0-dev 
| |  summary: Finish 3.0 redesign. 
| | 
| o  changeset: 22:4c2f98fac54b 3.0-dev 
|/|  summary: Merge in the latest changes to 2.1/mainline. 
| | 
o |  changeset: 21:37df04521032 
| |  summary: Added tag 2.1 for changeset 39ecc520fc0a 
| | 
o |  changeset: 20:39ecc520fc0a 2.1 
|\ \ summary: 2.1 development is done. 
| | | 
| o | changeset: 19:208f3f9236af 2.1-dev 
| | | summary: Finish the 2.1 work. 
| | | 
| | o changeset: 18:4a024009a9d6 3.0-dev 
| | | summary: More redesign work. 
| | | 
| | o changeset: 17:00c416888c25 3.0-dev 
| |/| summary: Merge in changes from the 2.1 branch to keep the redesign current. 
| | | 
| o | changeset: 16:a57e781a0db1 2.1-dev 
| | | summary: More 2.1 work. 
| | | 
| | o changeset: 15:ddeb65402a61 3.0-dev 
| | | summary: More redesign work. 
| | | 
+---o changeset: 14:90f5d7a8af9a 3.0-dev 
| | | summary: Merge in the fire fixes. 
| | | 
| o | changeset: 13:78a949b67bb9 2.1-dev 
|/| | summary: Merge in the fire fixes. 
| | | 
o | | changeset: 12:6dfe9d856202 
| | | summary: Oh no everything is on fire, fix it in the mainline. 
| | | 
| o | changeset: 11:86767671dcdb 2.1-dev 
| | | summary: Smaller changes for 2.1. 
| | | 
| | o changeset: 10:25dec81d2546 3.0-dev 
| | | summary: Work more on the redesign. 
| | | 
+---o changeset: 9:42c7d689fb24 3.0-dev 
| |  summary: Start working on a complete redesign. 
| | 
| o  changeset: 8:3da99186ca7d 2.1-dev 
|/  summary: Start working on 2.1. 
| 
o  changeset: 7:9ba79361827d 
|  summary: Added tag 2.0 for changeset 755ed5c5e291 
| 
o  changeset: 6:755ed5c5e291 2.0 
|\  summary: Merge in the dev branch for 2.0. 
| | 
| o  changeset: 5:44a833fcc838 2.0-dev 
| |  summary: Finish work on 2.0. 
| | 
| o  changeset: 4:d7ba6aae1651 2.0-dev 
|/|  summary: Merge in the critical fix. 
| | 
o |  changeset: 3:968049f1b33a 
| |  summary: Fix a critical bug on the main branch. 
| | 
| o  changeset: 2:917869609b25 2.0-dev 
| |  summary: More work on the new version. 
| | 
| o  changeset: 1:f95798b9cb2e 2.0-dev 
|/  summary: Start working on version 2.0. 
| 
o  changeset: 0:8a3fb044d3f4 
     summary: Initial commit. 
+2

Bu iş akışını önerilen şekilde duydum ancak ana hatta bir devel dalı için anlamlı olmayan birkaç değişiklik olduğunda ne kadar iyi uygulandığından emin değildim. En son ana hat değişikliklerini devel şubesine nasıl dahil ettiğime inanıyorum. Ana hattan istenmeyen değişiklikleri nasıl ele alırım? "23 ve 27 simgelerini ana hattan birleştir", ancak diğer tüm değişiklikleri (veya birleştirildikten sonra geri alma) görmezden gelmek gibi bir şey ifade etmek mümkün mü? –

+4

23 ve 27'yi birleştirmek ve diğerlerini görmezden gelmek istiyorsanız, Transplant uzantısını istersiniz: http://mercurial.selenic.com/wiki/TransplantExtension Eğer her şeyi birleştirmek istiyorsanız ve 23 ve 27'yi geri almak istiyorsanız, hg backout 23 --merge; dev dalda iken backg 27 --merge 'back. –

+2

Bence "backout" komutu amacım için en uygun olanı. Test ettim ve yapmak istediğimi yapıyor. Geri çekilmede sadece birkaç değişiklik olduğunda iyi performans gösteriyor. Aksi takdirde, çok fazla istenmeyen değişikliklere sahip olursak, tarih grafiğini şişirirdi ve çok fazla manüel çalışma anlamına gelirdi ... ama bu durumda olmadığı sürece önerilerinden tamamen memnun kaldım :) Teşekkürler! –

İlgili konular