Difference between revisions of "Git Workflow"

From Net-SNMP Wiki
Jump to: navigation, search
(Managing patches in the Git Tree)
(Managing patches in the Git Tree)
Line 19: Line 19:
 
First off, lets start by looking at what the SVN tree looks like at the time it changed to Git.  In SVN, patches were applied to all the branches at once so the tree is very "branchey", but with no merges.
 
First off, lets start by looking at what the SVN tree looks like at the time it changed to Git.  In SVN, patches were applied to all the branches at once so the tree is very "branchey", but with no merges.
  
[[Image:Git-Workflow-T0.jpg]]
+
[[Image:Git-Workflow-T0.png]]
  
  
 
In SVN developers were encouraged to commit fixes to all the branches at once.  This will be a major change when switching to Git.
 
In SVN developers were encouraged to commit fixes to all the branches at once.  This will be a major change when switching to Git.

Revision as of 22:23, 21 April 2011

Proposed

This page describes a proposal for Net-SNMP and is not yet solidified into the current architecture. Thus, take the contents with a grain of salt as it is likely to change.

This page describes the Net-SNMP Git Workflow. Using the contents of this page, users should be able to learn how to create patches and developers can learn how to manage changes to the Net-SNMP Git Tree.

Policy Overview

These will likely make more sense after you've read the sections and examples below this.

  1. Patches should always be applied to the earliest branch it's expected to be included into.
  2. Branches should be merged upward into the branch above it. IE, V5-4-patches would be occasionally merged into V5-5-patches.
    • Changes in V5-4-patches that shouldn't go into V5-5-patches may need to be reverted by hand, but they should be rare.
  3. New features or complex bug fixes should go into their own branch, derived off of the earliest branch they should be applied against.
    • If a decision changes with respect to which branch it should eventually be merged into, use git rebase to move it's root.
    • Once stable itself, the completed feature or bug fix branch should be merged into the appropriate tree.
  4. New feature branches should always be based off of the master branch
    • features that require other new features that haven't been merged themselves may need to root off of the other feature until they get merged into the master.

Managing patches in the Git Tree

First off, lets start by looking at what the SVN tree looks like at the time it changed to Git. In SVN, patches were applied to all the branches at once so the tree is very "branchey", but with no merges.

Error creating thumbnail: Unable to save thumbnail to destination


In SVN developers were encouraged to commit fixes to all the branches at once. This will be a major change when switching to Git.