gitworkflow:triangularworkflow

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
gitworkflow:triangularworkflow [2015/09/14 20:10] – JulienCharbongitworkflow:triangularworkflow [2015/09/14 20:34] (current) – JulienCharbon
Line 7: Line 7:
   * Once these changes have been tested and have matured enough, up-port them on top of HEAD for review   * Once these changes have been tested and have matured enough, up-port them on top of HEAD for review
   * Once review accepted, push them in HEAD   * Once review accepted, push them in HEAD
-  * Rebase changes that have not yet been accepted from ''%%releng/X.Y%%'' branch to new ''%%releng/X.(Y+1)%%'' branch+  * Rebase changes that have not yet been accepted to old ''%%releng/X.Y%%'' branch to new ''%%releng/X.(Y+1)%%'' branch
  
-For experimented git users this workflow is only common sense, but might help some to start %%FreeBSD%% contributions with a straighforward workflow.+For experimented git users (i.e. users that already fell in every git pitfalls) this workflow is common sense, but might help some to start %%FreeBSD%% contributions with a straightforward workflow.
  
 {{gitworkflow/triangularworkflow/git-47.png}} {{gitworkflow/triangularworkflow/git-47.png}}
Line 17: Line 17:
 This workflow assumes you use multiple repositories, i.e.: This workflow assumes you use multiple repositories, i.e.:
  
-origin repository:: Our own personal/corporate repository with full access, e.g. ''%%https://github.com/user/freebsd/%%''+  * **origin repository**: Our own personal/corporate repository with full access, e.g. ''%%https://github.com/user/freebsd/%%''
  
-upstream repository:: The official %%FreeBSD%% repository with read-only access, e.g. ''%%https://github.com/freebsd/freebsd/%%''+  * **upstream repository**: The official %%FreeBSD%% repository with read-only access, e.g. ''%%https://github.com/freebsd/freebsd/%%''
  
   * **Main workflow rules being**   * **Main workflow rules being**
     * Changes coming from ''%%upstream%%'' repository are merged     * Changes coming from ''%%upstream%%'' repository are merged
-    * Changes develop in ''%%origin%%'' repository are rebased+    * Changes developed in ''%%origin%%'' repository are rebased
  
 ====== Local Git Repository First Steps ====== ====== Local Git Repository First Steps ======
Line 53: Line 53:
 10.1-next/ 10.1-next/
 10.2-next/ 10.2-next/
 +master
 </code> </code>
  
-The ''%%X.Y-next%%'' branches are where changes/fixes are developed.  These branches are created from corresponding upstream release branches ''%%releng/X.Y/%%'' from upstream repository.  See below how they are created.+The ''%%X.Y-next%%'' branches are where changes/fixes are developed.  These branches are created from corresponding upstream release branches ''%%releng/X.Y/%%'' from upstream repository.  ''%%master%%'' branch is just ''%%CURRENT%%'', and used for review creation.  See below how they are created.
  
 ====== Create a X.Y-next Branch and Publish it ====== ====== Create a X.Y-next Branch and Publish it ======
Line 86: Line 87:
 </code> </code>
  
-====== Make and Publish Custom Changes ======+====== Create master Branch and Publish it ======
  
-Checkout local work branch and get last remote changes+Get last upstream changes 
 + 
 +<code> 
 +$ git fetch upstream 
 +</code> 
 + 
 +Create new ''%%master%%'' branch from corresponding ''%%upstream/master%%'' ''%%CURRENT%%'' branch 
 + 
 +<code> 
 +$ git checkout -t upstream/master 
 +</code> 
 + 
 +Publish ''%%master%%'' branch to origin repository 
 + 
 +<code> 
 +$ git push origin HEAD 
 +</code> 
 + 
 +====== Make and Publish Custom Changes in Origin Repository ====== 
 + 
 +Checkout ''%%X.Y-next%%'' branch and get last origin changes
  
 <code> <code>
Line 95: Line 116:
 </code> </code>
  
-Make source code changes and locally commit them+Make changes and locally commit them
  
 <code> <code>
Line 101: Line 122:
 # Hack, test, hack # Hack, test, hack
 $ git add foo/bar.c $ git add foo/bar.c
-$ git commit -m "[bz#42]: Fix this issue"+$ git commit -m "[bz#42]: Fix this issue/Improve performances"
 </code> </code>
  
-Once tested, rebase on top of last origin repository changes, and publish yours+Once tested, rebase on top of last origin repository changes, and publish
  
 <code> <code>
Line 113: Line 134:
 ====== Merge Errata/Security Patches from Upstream ====== ====== Merge Errata/Security Patches from Upstream ======
  
-  * **Note**: No Operating System is without sins, thus you need to merge Errata/Security patches from corresponding release branch+  * **Note**: No Operating System is without sins, thus you need to merge Errata/Security patches from corresponding release branch in a timely manner
  
-Checkout local work branch and get last origin changes+Checkout ''%%X.Y-next%%'' branch and get last origin changes
  
 <code> <code>
Line 122: Line 143:
 </code> </code>
  
-Get last upstream changes and check the log for Errata/Security information+Get last upstream changes and check the log for Errata/Security details
  
 <code> <code>
Line 129: Line 150:
 </code> </code>
  
-Merge last changes from upstream release branch+Merge last upstream changes from corresponding release branch
  
 <code> <code>
Line 135: Line 156:
 </code> </code>
  
-Resolve conflicts if any, than check final result+Resolve conflicts if any, than check the result
  
 <code> <code>
Line 141: Line 162:
 </code> </code>
  
-Publish merged upstream changes in orign+Publish merged upstream changes in origin
  
 <code> <code>
Line 147: Line 168:
 </code> </code>
  
-Next you can update %%FreeBSD%% release number in ''%%release/Makefile%%'' and create your private tag for release purpose.  See below.+Next you can update %%FreeBSD%% release number in ''%%release/Makefile%%'' and create your own tag for release/testing purpose.  See below.
  
-===== Create Private Tag and Publish it =====+===== Create Tag and Publish it =====
  
 <code> <code>
Line 156: Line 177:
 </code> </code>
  
-===== Checkout a Private Tag =====+===== Checkout a Tag =====
  
 <code> <code>
Line 164: Line 185:
 ====== Rebase Custom Changes onto a New Release Branch ====== ====== Rebase Custom Changes onto a New Release Branch ======
  
-Get all origin and upstream repositories changes.  For example to rebase changes made in 10.1-next to 10.2-next+Get all origin and upstream repositories changes.  For example to rebase your changes made in ''%%10.1-next%%'' to ''%%10.2-next%%''
  
 <code> <code>
Line 175: Line 196:
 </code> </code>
  
-Start an interactive rebase for all changes made in X.Y to X.(Y+1)+Start an interactive rebase for all changes made in ''%%X.Y%%'' to ''%%X.(Y+1)%%''
  
 <code> <code>
Line 183: Line 204:
   * **Note**: See [[/Interactive rebase|https://help.github.com/articles/interactive-rebase]] documentation   * **Note**: See [[/Interactive rebase|https://help.github.com/articles/interactive-rebase]] documentation
  
-  * **Note**: Rebase is smart enough to skip all already accepted changes the new ''%%X.(Y+1)-next%%'' branch, i.e. git rebase skips all commit that introduce an exact same change+  * **Note**: Rebase is smart/dumb enough to skip all already accepted included the new ''%%X.(Y+1)-next%%'' branch
  
-  * **Note**: Rebase will skip all Errata/Security merge, this is the default git rebase behaviour and that you actually want as all Errata/Security changes you want are already in ''%%X.(Y+1)-next%%'' branch by definition of a %%FreeBSD%% release branch+  * **Note**: Rebase will skip all Errata/Security merge commits, this is the default behaviour and that you actually want as all Errata/Security changes are already in ''%%X.(Y+1)-next%%'' branch by definition of a %%FreeBSD%% release branch
  
 During the interactive rebase you have in opportunity to: During the interactive rebase you have in opportunity to:
  
   * Remove now irrelevant changes   * Remove now irrelevant changes
-  * Squash (flatten) changes related to same fix/feature implementation in only one commit:+  * Squash changes related to same fix/feature implementation in only one commit:
     * Make things easier for future rebases     * Make things easier for future rebases
     * Make history easier to read     * Make history easier to read
     * Cleaner patch for upstream proposal     * Cleaner patch for upstream proposal
 +  * Re-order your changes
  
 This is different workflow than the classical SVN vendor model merge workflow, here we want to see our changes always on top of the last release branch: This is different workflow than the classical SVN vendor model merge workflow, here we want to see our changes always on top of the last release branch:
   * Custom changes will appear clearly   * Custom changes will appear clearly
-  * Custom changes will be on top the last release version, and be easier to propose them to upstream, and for future rebases+  * Custom changes will be on top the last release version, and be easier to propose them to upstream
  
 ====== Advantages/Disadvantages ====== ====== Advantages/Disadvantages ======
Line 203: Line 225:
 ===== Advantages ===== ===== Advantages =====
  
-  * Use last release branch for stability +  * Use of last release branch for stability 
-  * Custom changes/fixed are used/tested in production first +  * Custom changes/fixed are used/tested in production before review 
-  * No need to wait upstream for fixes and improvements+  * No need to wait upstream acceptation before enjoying fixes and improvements
   * These changes make great candidates for MFC (Merge From Current) once accepted in CURRENT   * These changes make great candidates for MFC (Merge From Current) once accepted in CURRENT
-  * Keep patches clean over release branches +  * Keep patches clean over new release branches 
-  * The origin repository includes only the branches you are working on/ you care about (it is not a full fork of the upstream repository) +  * The origin repository includes only the branches you are working on/you care about.  It is not a full complete fork of the upstream repository 
-  * Interface nicely with %%FreeBSD%% reviews (Phabricator/arc)+  * Interface nicely with %%FreeBSD%% reviews (Phabricator/arc) (see below)
  
 ===== Disadvantages ===== ===== Disadvantages =====
  
-  * Development is not done in CURRENT first +  * Development is not done in CURRENT 
-  * Patches are “up-ported” to HEAD once tested/have matured enough+  * Patches are “up-ported” to CURRENT once tested/have matured enough
   * Patches are in two branches until accepted:   * Patches are in two branches until accepted:
-    * X.Y-next (Release Branche) +    * ''%%X.Y-next%%'' (Release branch) 
-    * feature-review (Branch for Patch Proposed to Upstream)+    * ''%%feature-review%%'' (Branch for upstream review) (see below)
  
-====== More Usages examples ======+====== More Usages Examples ======
  
-===== Cherry-pick Specific Commits from Upstream =====+===== Creating a Review for CURRENT from X.Y-next branch =====
  
-Note: You might want sometimes to MFC a change from ''%%CURRENT%%'' to you ''%%X.Y-next%%'' branch +Checkout last changes from ''%%upstream/master%%''
- +
-Checkout local work branch and get last origin changes+
  
 <code> <code>
-$ git checkout 10.2-next+$ git fetch upstream 
 +$ git checkout master
 $ git pull --rebase $ git pull --rebase
 </code> </code>
  
-Get last upstream changes and check the log for the SHA of the commit(s) to cherry-pick+Create review branch
  
 <code> <code>
-$ git fetch upstream +$ git checkout -b feature-foo-review master 
-$ git log upstream/master+$ git push -u origin HEAD # It creates the base commit for the review
 </code> </code>
  
-  * **Note**: One may select any branch from which to cherry pick specific commits. +Cherry-pick changes related to "feature foo" from ''%%X.Y-next%%'' branch
- +
-Cherry-pick changes from ''%%upstream/master%%''+
  
 <code> <code>
-$ git cherry-pick $SHA+$ git log origin/10.2-next # Note SHA strings of desired commits 
 +$ git cherry-pick $SHA1 $SHA2
 </code> </code>
  
-  * **Note**: Where $SHA is the SHA string of the commit to cherry-pick +and create the review
- +
-Resolve conflicts and check commit merge diff+
  
 <code> <code>
-$ git log -p 
-</code> 
- 
-Publish cherry-picked upstream changes to origin repository 
- 
-<code> 
-$ git pull --rebase 
-$ git push origin HEAD 
-</code> 
- 
-===== Creating a Review for CURRENT from X.Y-next branch ===== 
- 
-Checkout last changes from ''%%upstream/master%%'' 
- 
-<code> 
-$ git fetch upstream 
-$ git checkout -b master upstream/master 
-$ git pull --rebase 
-</code> 
- 
-Create review branch, and put your changes related to "feature foo" in it, and create the review 
- 
-<code> 
-$ git checkout -b feature-foo-review master 
-$ git push -u origin HEAD # It creates the base commit for the review 
-$ git log origin/10.2-next # Get SHA strings of desired commits 
-$ git cherry-pick $SHA1 $SHA2 
 $ arc which # Check that commit $SHA1 and $SHA2 will be part of the review $ arc which # Check that commit $SHA1 and $SHA2 will be part of the review
-$ arc diff --create+$ arc diff --create # Create review D1234
 </code> </code>
  
-==== Update your Review with more Changes ====+==== Update your Review ====
  
 If during review changes are required, local commit the desired changes and include them in the review If during review changes are required, local commit the desired changes and include them in the review
Line 291: Line 282:
 # Hack, test, hack # Hack, test, hack
 $ git add foo/bar.c $ git add foo/bar.c
-$ git commit -m "Address comment #X from review D1234"+$ git commit -m "Address comments from review D1234"
 $ arc which # Check that all desired commits are part of the review $ arc which # Check that all desired commits are part of the review
 $ arc diff --update D1234  $ arc diff --update D1234 
Line 300: Line 291:
 If the review takes a while, you can rebase your changes on top of the current master and update the review. If the review takes a while, you can rebase your changes on top of the current master and update the review.
  
-First get last master changes+First get last upstream changes
  
 <code> <code>
Line 312: Line 303:
 $ git checkout feature-foo-review $ git checkout feature-foo-review
 $ git rebase master $ git rebase master
 +</code>
 +
 +And update the review
 +
 +<code>
 $ git push origin master:feature-foo-review # Update the review base commit $ git push origin master:feature-foo-review # Update the review base commit
 $ arc which # Check that the review includes all desired commit changes, and only them $ arc which # Check that the review includes all desired commit changes, and only them
 $ arc diff --update D1234 $ arc diff --update D1234
 +</code>
 +
 +===== Cherry-pick Specific Commits from Upstream =====
 +
 +Note: Sometimes You might want to get a change from ''%%CURRENT%%'' to your ''%%X.Y-next%%'' branch
 +
 +Checkout ''%%X.Y-next%%'' branch and get last origin changes
 +
 +<code>
 +$ git checkout 10.2-next
 +$ git pull --rebase
 +</code>
 +
 +Get last upstream changes and check the log for the SHA of the desired commit(s) to cherry-pick
 +
 +<code>
 +$ git fetch upstream
 +$ git log upstream/master
 +</code>
 +
 +Cherry-pick desired changes from ''%%upstream/master%%''
 +
 +<code>
 +$ git cherry-pick SHA
 +</code>
 +
 +  * **Note**: Where SHA is the SHA string of the commit to cherry-pick
 +
 +Resolve conflicts and check result
 +
 +<code>
 +$ git log -p
 +</code>
 +
 +Publish cherry-picked changes to origin repository
 +
 +<code>
 +$ git pull --rebase
 +$ git push origin HEAD
 </code> </code>
  
  • gitworkflow/triangularworkflow.1442261442.txt.gz
  • Last modified: 2015/09/14 20:10
  • by JulienCharbon