4. Basic/ Centralized Workflow
The most basic Git Workflow
• Something like SVN workflow
• Advantages over SVN:
• Local copy of entire project
• Branching and merging model
• All changes are committed into master
branch (SVN trunk equivalent)
6. Feature Branch Workflow
Branch by feature
• Master branch represents the code base (final solution)
• Each developer works on its own feature
• This workflow avoid broken code
• Share feature with other developer without change master branch
• Code Review is the major advantage of using pull requests
• Join feature into master branch
• Discuss changes between developers
8. Gitflow Workflow
Gitflow
• Proposes
• Managing feature development
• Release preparation
• Maintenance
• More complex than Feature Branch Workflow
• Main branches:
• master – stores the official release history
• develop – serves as an integration branch for features
• Feature branches
• Each feature branch should reside on its branch
• The feature branch isn’t merged into master directly, it should be
merged on develop branch
9. Gitflow Workflow
Gitflow
• Release Branches
• When develop branch has enough features for a release it’s time to
create a new branch from develop – Release Branch
• This action starts a new release cycle
• New feature can’t be added
• Only can be added bug fixes, documentation and tasks
related with the release process
• When the release is ready to deliver, the release branch should be
merged into master and develop and a new tag should be created.
10. Gitflow Workflow
Gitflow
• Maintenance Branches
• Also known as a hotfix branch
• Unique branch that should be created from master branch
• When the fix is complete, the branch should be merged into master
and develop or the current release branch
• Master branch should be tagged with the current version
12. Forking Workflow
Forking Workflow
• It’s different from other workflows already presented here
• There is no central repository
• Each developer has a server-side repository (public) and a local repository
(private)
• Developers push to their own server-side repositories
• Only the project maintainer can push to the official repository
• In this way, project maintainer accept commits from any developer without
giving them access to the official codebase
• Bitbucket and Github are examples of using this workflow.