Skip to content

Instantly share code, notes, and snippets.

@perigrin
Forked from nothingmuch/gist:143993
Created July 9, 2009 21:26
Show Gist options
  • Save perigrin/144013 to your computer and use it in GitHub Desktop.
Save perigrin/144013 to your computer and use it in GitHub Desktop.
New branching layout for Moose/Class-MOP
main branches:
master
stable
branches
topics
people:
authors - people creating a branch
comitters - people reviewing and merging a branch
cabal - people who can release moose
stable (refs/heads/stable) = the branch that releases are made off when making
a new release you merge from master to stable. Only updated by cabal during a
release process.
master (refs/heads/master) = the branch new development is merged into and
branched from
branches (refs/heads/*) = large community branches for big development.
"projects"
topics (refs/heads/topics/*) = small/personal branches that have been published
for review, but can get freely rebased. Targetted features that may span a
handful of commits.
Bug/Feature workflow:
# update your copy of master
git checkout master
git pull --rebase
# create a new topic branch
git checkout -b topic/my_feature
# hack, commit, feel free to break fast forward
commit --amend # allowed
git rebase --interactive # allowed
push --force origin topic/my_feature # allowed
Then go on IRC, ask for someone to review and merge to master. If it merges
cleanly and nobody has any objections then it can be pushed to master.
If it doesn't merge as a fast forward the author needs to run
git rebase origin/master
or
git merge origin/master
and make sure it will merge as a fast forward.
No actual merging (as in a human resolving conflicts) should be done when
merging into master, only from master.
Emergency bug workflow (for immediate release):
git checkout stable
git pull --rebase
git checkout -b topic/my_emergency_fix
hack
commit
Then a cabal member merges into stable:
git checkout stable
git merge topic/my_emergency_fix
git push
# release
git checkout master
git merge stable
Project workflow:
for longer lasting branches we use a subversion style branch layout, where
master is routinely merged into the branch. Rebasing is probably not a good
idea if there are multiple contributers on such branches.
Committing is still done with the same review process as a topic branch, and
the branch must merge as a fast forward.
This is pretty much the way we're doing branches for largeish things right now.
Copying the 'pu' branch idea:
To make things easier for longer lived branches (whether topics or projects),
the 'pu' branch is basically what happens if you merge all of the branches and
topics together into master, as long as they merge cleanly. We can update this
as necessary (e.g. on a weekly basis if there is merit), telling the authors of
the respective branches if their branches did not merge (and why), and running
the test suite.
To update 'pu':
git checkout pu
git reset --hard origin/master
git merge @all_the_branches
If the merge is clean, 'pu' is updated with push --force.
If the merge is not clean, the offending branch is removed from
@all_the_branches, with a small note of the conflict, and we try again.
The authors of the failed branches should be told to try and merge their branch
into 'pu', to see how their branch interacts with other branches.
'pu' is probably broken most of the time, but lets us know how the different
branches interact
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment