From 3396f9a4e3d202bc65ca029dd49e82bba0a4b08f Mon Sep 17 00:00:00 2001 From: Ralf Wildenhues Date: Sat, 31 Jul 2010 17:00:48 +0200 Subject: Add example git work flow; discuss merge --log in HACKING. * HACKING: Update. Suggestion by Stefano Lattarini. Signed-off-by: Ralf Wildenhues --- HACKING | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) (limited to 'HACKING') diff --git a/HACKING b/HACKING index 8facbeb58..f25a0e016 100644 --- a/HACKING +++ b/HACKING @@ -113,6 +113,30 @@ suitable testing. It is advisable to merge only after a set of related commits have been applied. +* Example work flow for patches to maint: + + # 1. Checkout the "maint" branch: + git checkout maint + + # 2. Apply the patch(es) with "git am" (or create them with $EDITOR): + git am -3 0*.patch + # 2a. Run required tests, if any ... + + # 3. Merge maint into branch-1.11: + git checkout branch-1.11 + git merge maint + # 3a. Run required tests, if any ... + + # 4. Redo steps 3 and 3a for master: + git checkout master + git merge maint + # testing ... + + # 5. Push the maint and master branches: + git push --dry-run origin maint branch-1.11 master + # if all seems ok, then actually push: + git push origin maint branch-1.11 master + * For bug fixes of long-standing bugs, it may be useful to commit them to a new branch based off of the commit that introduced the bug, and merge this bugfix branch into active branches that descend from the buggy commit. @@ -123,6 +147,10 @@ common ground for feature merging and testing, should they not be ready for master yet. +* For merges from branches other than maint, prefer 'git merge --log' over + plain 'git merge', so that a later 'git log' gives an indication of which + actual patches were merged even when they don't appear early in the list. + * master and release branches should not be rewound, i.e., should always fast-forward, except maybe for privacy issues. The maint branch should not be rewound except maybe after retiring a release branch or a new stable -- cgit v1.2.1