mercurial - HgFlow and multiple developers -


i hg flow mercurial repositories. using bitbucket, , in each product multiple developers working. can work below:

  • a team might work on single feature.
  • another team might work on release/hot fix.

so keep "develop" branch in bitbucket or local repositories. , how feature branches, should push them central repository , remove when required. assume should right?

thanks

i neither use git flow or hg flow tools, use of methods own projects (manually).

before going detail, need provide branches in main/bitbucket repository when multiple people need merge or branch them. definately includes "develop" , features/fixes multiple people need work on (unless have repository or method exchange branches/commits between them)

the difference between using git , mercurial/hg relevant here, since branching models quite different. see a guide branching in mercurial details. using hg bookmarks quite similar git branches, there no full support bookmark branching model on bitbucket (see this ticket).

hg flow (the tool) uses named branches. in contrast git branches, these not @ light-weight, permanent , global (they can @ least closed now). means whenever commit created on (named) branch other "default" pushed bitbucket (even after merging) create branch in bitbucket repository.

so don't have other choice keeping all branches in main repository. however, can decide when push , when close these. advise using hg push -r push branches/heads want push , pushing these when either needed else or finished , merged. branches should closed not needed anymore. (this done hg flow automatically) should close branches locally whenever possible. way might not appear in bitbucket interface. might reach bitbucket repository in closed state (which hides them interface).

obviously should push branches multiple people need merge from. in understanding of workflow "develop" branch 1 branch per project should pushed (after local testing).


in case either not using hg-flow or named branches things bit different. both, using forks/clones or bookmarks branching method doesn't generate permanent or global branches.

like mentioned above, can't use bookmarks (reliably) when want use bitbucket pull requests. have push bookmarks separately. normal push update (a head of) branch might miss commits other team members when marging later. hg tell when new head created. in case might want merge branch remote bookmark branch before pushing.

when using forks branches works bit bookmarks, bitbucket has full support that. need have new fork on bitbucket every branch. naturally want create forks if need different people work on , don't have other means of commit exchange them. need @ least separate "develop" repository then.


i wouldn't use full "flow" hg on bitbucket. projects "develop" branch same master/default, since don't roll out releases git (other development builds, wouldn't use release branch anyways). don't need separate "production" branch, since tags can used production usage. don't create separate "release-preparation" branch. there point in time when apply bugfixes on develop , stop merging features. won't work when need work @ same time on features dependendant on features not released in next release.

always using full "git flow" easy because git branching easy , light-weight. depending on branching model use , how supportive other tools are, using full "hg flow" might not "worth it".

the hg guide discourages use of named branches short-lived branches. see feature separation through named branches. "easy" branching concept promoted in guide forking/cloning. bookmarks natural way translate git flow if tool/bitbucket support better (and bookmarks longer core hg feature).


disclaimer: prefer git when can choose. use hg, not personal choice.

you might have considered of this, since didn't state of these details , accept answer (in comments) quite different asking, wanted elaborate bit.


edit:

to follow-up on comments:

i think hg bookmarks comparable git branches because both movable pointers commits. main difference is, when delete branch in git, commits possibly lost (when not part of other branches or pointed in branch before garbage collected). when delete bookmark in hg, commits still part of repository (part of (named or default) branch) unless manually stripped.

anonymous heads related, bookmarks point to. without bookmarks pointing them anonymous heads not usable branch work (for more local merge) , share. when have anonymous heads in repository don't know supposed or came from, unless remember or have other clues. in eyes anonymous heads workaround late implementation of bookmarks , no implementation of remotes/remote heads.

named branches rather unrelated, thing have in common git branches having name. light-weight in comparision cloning whole repository (forking branch model), not in terms of "you can't rid of them". permanent. places tell not use named branches unless have reason or long-running branch.


Comments

Popular posts from this blog

java.util.scanner - How to read and add only numbers to array from a text file -

rewrite - Trouble with Wordpress multiple custom querystrings -