miscellaneous-slides
git workflows (for subversion projects)
in the beginning (subversion / trunk based)
- your project started as a subversion project
- with subversion you don‘t do branches …
- even if you branch - you never merge!
in the past (first git experience / feature branches)
- now you have feature branches almost everywhere
- development is automatically deployed from master
- production is manually deployed from master
- releases are manually tagged on master
time to review the process …
- for the development environment ci/cd works great
- for production deployments you still need manual steps
- some features from development get approved slowly
- other features in development need to be deployed asap!
- for production deployments you still need code-freezes
- i.e. you still hold back pull requests before deployments
- improve ci/cd for all environments (development, testing, production)
evaluate different git workflows … Trunk Based Development
evaluate different git workflows … Git Flow
evaluate different git workflows … GitHub Flow
evaluate different git workflows … GitLab Flow
evaluate different git workflows … Git Flow (enhanced)
choose a git workflow! problem?
How to Select a Git Branch Mode?
Considering Product Type and Release Method, Team Size, Collaboration Maturity:
| Product type and release method | Team size | Collaboration maturity | Applicable branch mode |
|---|---|---|---|
| All (?) None (?) | Small | High | Trunk Based Development |
| Products that support continuous deployment and release, such as Web applications or SaaS products. | Middle | Moderate | GitHub-Flow and TBD |
| Products with a definite release window and a periodic version release cadence, such as iOS apps. | Middle | Moderate | Git-Flow and GitLab-Flow |
| Products that are demanding for product quality and support continuous deployment and release, such as basic platform products. | Middle | Moderate | GitLab-Flow |
| Products that are demanding for product quality and have a long maintenance cycle for released versions, such as 2B basic platform products. | Large | High | Git-Flow |
Considering from the perspective of the number of required release versions:
- If a product needs to support multiple release versions, use Git-Flow.
- If a simple product needs to support a single release version, use GitHub-Flow or TBD.
- If a complex product needs to support a single release version, use GitLab-Flow.
GitLab Flow – Best Practices
- Use feature branches, no direct commits on main.
- Test all commits, not only the ones on main.
- Run all the tests on all commits (have them run in parallel).
- Perform code reviews before merges into main, not afterwards.
- Deployments are automatic, based on branches or tags.
- Tags are set by the user, not by CI/CD.
- Releases are based on tags.
- Pushed commits are never rebased.
- Everyone starts from main, and targets main.
- Fix bugs in main first and release branches second.
- Commit messages reflect intent.
GitLab Flow – branch layout
Advantages
- Environment branches define the CI/CD pipeline
- The git history will be cleaner and more readable
- Ideal when there is a single version in production
Improving Continuous Delivery with GitLab Flow
- All code changes flow in one direction (less conflicts)
- Building new instances for any environment is easy
- Comparing code from different stages becomes easy
Links
- A successful Git branching model | Vincent Driessen
- Choosing the Right Git Branching Strategy | Medium
- Comparing four branching workflows for Git | Medium
- How to Select a Git Branch Mode? | Alibaba Cloud Blog
- Improving Continuous Delivery with GitLab Flow | exawizards
- Trunk-Based Development: A Love & Hate Story | Medium
- What are GitLab Flow Best Practices? | GitLab
- Write Better Commits, Build Better Projects | GitHub Blog
Thank you very much for your attention. Any questions?
