-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So I'm really not sure how other Git-using projects deal with branches, but I wanted to propose how to deal with them, at least in the near-term, while we stabilize the 1.10 branch for a release candidate.
In the past, we committed wherever it made sense, and then cherry-picked to related branches. This worked, but over time, the branches' histories diverged further and further, and rebasing got difficult. To retain history better, I am proposing this: * 1.8 gets no changes other than Really Important Bug Fixes (TM) -> cherry-pick to: * 1.10 gets bug fixes and stabilization changes and no major features -> merge to: * master (1.11) So if you make a Really Important Bug Fix(TM) in 1.8, you would cherry-pick it to 1.10. Any changes to 1.10 should be merged with "git merge" to master, to go into 1.11 (future 1.12). This will ensure that 1.11 is *always* a superset of 1.10, and that they share the same history. I believe if we work with the branches this way, it will be easier to make changes based on 1.10 and rebase them to work against 1.11 instead, or vice-versa. HOWEVER, while I've worked with Git branching quite a bit at this point, I'm not clear if this is really the best way to deal with maintaining multiple branches. If any of you out there in opennms-devel-land have suggestions, I am open to scrapping all this and doing it a better way. =) Anyways, here's a basic workflow. Note that I did not use any shortcuts; normally you can use "git checkout -b" to create and check out a branch at once, you can "git pull" to fetch and merge in one step, and so on. I wanted to expose the plumbing a bit and show how git deals with things internally. ### step 0: make sure you've got the latest upstream changes git fetch #### step 1: fix an important bug in the 1.8 stable branch # make a local branch from the 1.8 remote branch # you can skip this step if you've already done so git branch --track 1.8 origin/1.8 # check out the local 1.8, and make sure it's up-to-date # with the latest changes in origin's 1.8 git checkout 1.8 git merge --ff origin/1.8 # make your changes in 1.8 and commit git add . git commit -m 'NMS-XXXX fix for really important thing' # this will say it committed a change like so: # [1.8 82c1c86] NMS-XXXX fix for really important thing # 1 files changed, 1 insertions(+), 0 deletions(-) #### step 2: cherry-pick that change to the 1.10 stable branch # make a local branch from the 1.10 remote branch # you can skip this step if you've already done so git branch --track 1.10 origin/1.10 # check out the local 1.10, and make sure it's up-to-date # with the latest changes in origin's 1.10 git checkout 1.10 git merge --ff origin/1.10 # cherry-pick the change to the 1.10 branch, this will be the same # hash that you saw in the commit message above git cherry-pick 82c1c86 # if the cherry-pick failed, fix the merge, and then do this, # otherwise skip this part: git add . git commit -c 82c1c86 #### step 3: merge to master # check out the latest master git checkout master git merge --ff origin/master # merge the changes from the 1.10 branch to master git merge 1.10 #### step 4: push all the changes # git push <remote-name> <local-branch>:<remote-branch> # shorter version: git push origin 1.8 1.10 master git push origin 1.8:1.8 git push origin 1.10:1.10 git push origin master:master - -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFN3nHzUu+jZtP2Zf4RAiYYAKCV5IQzdqqRz/YKw0qbdA7+eFhkxACfbHj6 aqwI61E5TXTiXchNXFRf75o= =CdO6 -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Please read the OpenNMS Mailing List FAQ: http://www.opennms.org/index.php/Mailing_List_FAQ opennms-devel mailing list To *unsubscribe* or change your subscription options, see the bottom of this page: https://lists.sourceforge.net/lists/listinfo/opennms-devel
