This is my branching strategy, which should work well for any development from a single developer to a small team.
The goal for the strategy is to minimize branching, and administrative tasks.
For large team development a completetly different approach is needed.
Here is the strategy described in words:
* Use Master branch as development branch.
* When it is time for a release,
- tag the commit, ex v1.0
- create a branch, ex v1.0
* Continue development on Master branch
* Make corrections/fixes for v1.0 release on branch 1.0
* Merge fixes back to development/master branch (if needed)
Some ascii art to show the workflow
tag 1.0 1.1 ---------*------------------*------------*------------------*-------> Master \ / \ / \ / \ v1.1 /v1.1.1 \ v1.0 / v1.0.1 -------------*------> 1.1 -----------*-------> 1.0
Here is a small example
git init
echo "some text" > a.txt
git add a.txt
git commit
echo "some more text" > a.txt
git commit -a
git tag -a v1.0 -m 'version 1.0'
git branch v1.0
git checkout v1.0
echo "third row of text, on new branch" > a.txt
git commit -a
git checkout master
echo "third row of text on master branch" > a.txt
git commit -a
git merge 681d9911379f4bed16903c876b72243e3de7d4dd
git log --graph --pretty=oneline --abbrev-commit
The resulting git tree.
* 0ffb123 Merge commit '681d9911379f4bed16903c876b72243e3de7d4dd' |\ | * 681d991 Text added on v1.0 branch * | 5c8800b Third row of text on master branch |/ * 0496fc8 Added a second row of text to a.txt * f5251a8 Initial commit, adding file a.txt
Sorry, the comment form is closed at this time.