1. GIT LAB FLOW
1.1. Advantages
1.1.1. defines how to make the Continuous Integration and Continuous Delivery
1.1.2. git history will be cleaner, less messy and more readable
1.1.3. ideal when it needs to maintain a single version in production
1.1.4. It advocates the Feature Driven Development
1.2. Disadvantaes
1.2.1. more complex that the GitHub Flow
1.2.2. It can become complex as Git Flow when it needs to maintain multiple version in production
1.3. Rules Of The Git Lab Flow
1.3.1. Use feature branches, no direct commits on master
1.3.2. Test all commits, not only ones on master
1.3.3. Run all the tests on all commits
1.3.4. Perform code reviews before merges into master, not afterwards.
1.3.5. Deployments are automatic, based on branches or tags.
1.3.6. Tags are set by the user, not by CI.
1.3.7. Releases are based on tags.
1.3.8. Pushed commits are never rebased.
1.3.9. Everyone starts from master, and targets master.
1.3.10. Fix bugs in master first and release branches second.
1.3.11. Commit messages reflect intent.
2. ONE FLOW
2.1. Advantages
2.1.1. The git history will be cleaner, less messy and more readable (squash&merge)
2.1.2. It is flexible according to team decisions
2.1.3. It is ideal when it needs to maintain a single version in production
2.1.4. drop-in replacement for GitFlow
2.2. Disadvantages
2.2.1. It isn’t recommended for projects with Continuous Delivery or Continuous Deploy.
2.2.2. The feature branches make it harder the Continuos Integration
2.3. Rules Of The One Flow
2.3.1. There is a main branch (eg: master)
2.3.2. Development branch for the day-to-day work. It is used to develop new features and bug-fixes for the upcoming release
3. GIT FLOW
3.1. Advantages
3.1.1. Ensures a clean state of branches at any given moment in the life cycle of project
3.1.2. The branches naming follows a systematic pattern making it easier to comprehend
3.1.3. It has extensions and support on most used git tools
3.1.4. ideal when it needs to maintain multiple version in production
3.2. Disadvantages
3.2.1. The Git history becomes unreadable
3.2.2. The master/develop split is considered redundant and makes the Continuous Delivery and the Continuos Integration harder
3.2.3. It isn’t recommended when it need to maintain single version in production
3.3. Rules of the Git Flow
3.3.1. master — this branch contains production code. All development code is merged into master in sometime.
3.3.2. develop — this branch contains pre-production code. When the features are finished then they are merged into develop.
3.3.3. feature-* — feature branches are used to develop new features for the upcoming releases. May branch off from develop and must merge into develop.
3.3.4. hotfix-* — hotfix branches are necessary to act immediately upon an undesired status of master. May branch off from master and must merge into master anddevelop.
3.3.5. release-* — release branches support preparation of a new production release. They allow many minor bug to be fixed and preparation of meta-data for a release. May branch off from develop and must merge into master anddevelop
4. GIT HUB FLOW
4.1. Advantages
4.1.1. it is friendly for the Continuous Delivery and Continuous Integration
4.1.2. A simpler alternative to Git Flow
4.1.3. It is ideal when it needs to maintain single version in production
4.2. Disadvantages
4.2.1. The production code can become unstable most easily
4.2.2. Are not adequate when it needs the release plans
4.2.3. It doesn’t resolve anything about deploy, environments, releases, and issues
4.2.4. It isn’t recommended when multiple versions in production are needed
4.3. Rules Of The Git Hub Flow
4.3.1. Anything in the master branch is deployable
4.3.2. To work on something new, create a branch off from master and given a descriptively name(ie: new-oauth2-scopes)
4.3.3. Commit to that branch locally and regularly push your work to the same named branch on the server
4.3.4. When you need feedback or help, or you think the branch is ready for merging, open a pull request
4.3.5. After someone else has reviewed and signed off on the feature, you can merge it into master
4.3.6. Once it is merged and pushed to master, you can and should deploy immediately