Git Workflow
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.
- Patches should always be applied to the earliest branch it's expected to be included into.
- 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.
- 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.
- 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.
In SVN developers were encouraged to commit fixes to all the branches at once. This will be a major change when switching to Git.