Branching Strategies

Surasuk Oakkharaamonphong
Technical Coach
INFINITAS by Krungthai
Branching Strategies

● Git Flow
● GitHub Flow
● Trunk Based Development
● GitLab Flow
[Link]
GitHub Flow

[Link]
Trunk Based Development

[Link]
GitLab Flow with Environment Branches

[Link]
staging

[Link]
Git Workflow Demo
Setup New Project
1. New Project
2. New Branch
a. production
b. staging
3. Setting
a. Repository => Protected branches
i. Branch
1. production
2. staging
ii. Allowed to merge => Maintainers
iii. Allowed to push and merge => No one
b. Merge requests
i. Merge method => Fast-forward merge
4. Project information => Members
a. Select a role => Developer
 Conventional Commits
A specification for adding human and machine readable
meaning to commit messages

[Link]
Commit Message Guidelines

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

● First line should be short and quickly describe the changes (Subject).
● Second line remains empty.
● Third line and more can include more info to the changes.
● Any line of the commit message cannot be longer 100 characters.

[Link]
Commit Message Guidelines - Type
● build: Changes that affect the build system or external dependencies
● ci: Changes to our CI configuration files and scripts
● docs: Documentation only changes
● feat: A new feature
● fix: A bug fix
● perf: A code change that improves performance
● refactor: A code change that neither fixes a bug nor adds a feature
● style: Changes that do not affect the meaning of the code
● test: Adding missing tests or correcting existing tests

[Link]
Commit Message Guidelines - Scope

● animations ● platform-browser
● common ● platform-browser-dynamic
● compiler ● platform-server
● compiler-cli ● platform-webworker
● core ● platform-webworker-dynamic
● elements ● router
● forms ● service-worker
● http ● upgrade
● language-service

[Link]
Commit Message Guidelines - Subject
● use the imperative, present tense: "change" not "changed" nor "changes"
● don't capitalize the first letter
● no dot (.) at the end

Commit Message Guidelines - Body

● Just as in the subject, use the imperative, present tense: "change" not
"changed" nor "changes". The body should include the motivation for the
change and contrast this with previous behavior.

[Link]
Commit Message Guidelines - Footer

● The footer should contain a closing reference to an issue if any.

Syntax Example

Keyword #IssueNumber close #10

● Linking a merge request to an issue using a keyword

○ close
○ fix
○ resolve

[Link]
Commit Message Guidelines - Specification
1. Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by the
OPTIONAL scope and REQUIRED terminal colon and space.
2. The type feat MUST be used when a commit adds a new feature to your application or library.
3. The type fix MUST be used when a commit represents a bug fix for your application.
4. A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of
the codebase surrounded by parenthesis, e.g., feat(api):
5. A description MUST immediately follow the colon and space after the type/scope prefix. The
description is a short summary of the code changes, e.g., fix: array parsing issue when multiple
spaces were contained in string.
6. A longer commit body MAY be provided after the short description, providing additional
contextual information about the code changes. The body MUST begin one blank line after the
description.
7. A commit body is free-form and MAY consist of any number of newline separated paragraphs.
8. One or more footers MAY be provided one blank line after the body. Each footer MUST consist
of a word token, followed by either a :<space> or <space># separator, followed by a string
value.
9. A footer’s token MUST use - in place of whitespace characters, e.g., Acked-by
[Link]
Commit Message Guidelines - Examples

● type enum
○ "foo: some message" # fails
○ "fix: some message" # passes
● type case
○ "FIX: some message" # fails
○ "fix: some message" # passes
● type empty
○ ": some message" # fails
○ "fix: some message" # passes

[Link]
Commit Message Guidelines - Examples

● subject case
○ "fix(SCOPE): Some message" # fails
○ "fix(SCOPE): Some Message" # fails
○ "fix(SCOPE): SomeMessage" # fails
○ "fix(SCOPE): SOMEMESSAGE" # fails
○ "fix(scope): some message" # passes
○ "fix(scope): some Message" # passes

[Link]
Commit Message Guidelines - Examples

● subject empty
○ "fix:" # fails
○ "fix: some message" # passes
● subject full stop (.)
○ "fix: some message." # fails
○ "fix: some message" # passes
● header max length (100)

[Link]
Commit Message Guidelines - Examples

● body leading blank

○ "fix: some message
body message" # warning
○ "fix: some message

body message" # passes

[Link]
Feature Requests
You can request a new feature by submitting an issue to our GitLab Repository. If
you would like to implement a new feature, please submit an issue with a proposal
for your work first, to be sure that we can use it. Please consider what kind of
change it is:

● For a Major Feature, first open an issue and outline your proposal so that it
can be discussed. This will also allow us to better coordinate our efforts,
prevent duplication of work, and help you to craft the change so that it is
successfully accepted into the project.
● Small Features can be crafted and directly submitted as a Merge Request.

[Link]
Submitting a Merge Request (MR)
1. Make your changes in a new git branch
2. Run the full test suite and ensure that all tests pass.
3. Commit your changes using a descriptive commit message that follows our
commit message conventions.
4. Push your branch to GitLab

[Link]
After your merge request is merged
1. Delete the remote branch on GitLab
2. Switch to main branch
3. Delete the local branch

[Link]
Jira Integration
Surasuk Oakkharaamonphong
Technical Coach
INFINITAS by Krungthai
Branching Strategies

● Enhance productivity by ensuring proper coordination among

developers
● Enable parallel development
● Help organize a series of planned, structured releases
● Map a clear path when making changes to software through to
production
● Maintain a bug-free code where developers can quickly fix
issues and get these changes back to production without
disrupting the development workflow

[Link]
Git Flow Pros
● Great for specific testing and compliance requirements
● Well suited for large teams
● Improved traceability between features and branches
● Support managing multiple versions

[Link]
Git Flow

[Link]
Git Flow Cons
● High learning curve
● Very complex process
● Difficult and lengthy path to production
● Dedicated release manager may be needed
● Merge conflicts are frequent and complex

[Link]
Advocating for Git Flow
● Engineers
○ Fewer merge conflicts
○ Fast process for production issues
● Engineering Leaders
○ Great for a large team with sub teams
○ Release manager lessens the burden
○ Reduces audit risk
● Auditors
○ Traceability
○ No unauthorized changes to production

[Link]
Git Flow
Pros Cons

● Easy to align work even over multiple ● A complicated model with lots of branches.
teams. That also means you have to backmerge
● Handling of multiple product versions. between some of those, which increases
● Every branch has a clear responsibility. complexity and increases also the chance
● We have a gate between active of merge conflicts.
development branch and production. ● It can slow down the development process
/ release frequency because of all of those
steps.
● It needs some majority of the team and
willingness to stick to it.

[Link]
GitHub Flow
Pros Cons

● Faster feedback cycles and short ● Once a feature branch is merged it is

production cycles production ready. If not tested properly
● Perfect for asynchronous work in smaller and backed by a strong CI/CD this can
teams easier introduce bugs
● Easier to understand than Git-Flow as it is ● Branches tend to live longer
"more agile" ● Can become tricky for bigger teams (e.g.
increased potential for merge conflicts)
● Supporting multiple release versions at a
time is very difficult

[Link]
Feature Branching

[Link]
GitLab Flow with Release Branches

[Link]
[Link]
GitLab Flow
Pros Cons

● Can handle multiple release versions or ● It can become very complex if you want to
even multiple stages maintain multiple versions.
● Simpler than Git-Flow ● More complex than GitHub-Flow
● Does focus more on quality with a lean
approach

[Link]
Trunk Based Development

[Link]
Trunk Based Development
● Centralized Workflow
● Single branch (main)
● commit directly to main
○ Short lived branches (<24 hours) are okay
● Main is always production ready
● CI/CD and feature flags are a must

[Link]
Trunk Based Development Pros
● Very simple workflow
● Codebase is always production ready
● Production matches latest commit
● Improved engineer experience
● Limited merge conflicts

[Link]
Trunk Based Development Cons
● Robust CI/CD pipeline is a must
● Restrictively low number of contributors
● Need for feature flags
● Senior engineers are needed
● Individual work becomes more difficult
● Limited traceability

[Link]
Advocating for Trunk Based Development
● Simple clean workflow
● Takes advantage of our CI/CD pipeline
● Faster delivery
● Easier bug fixes
● More coding, less process

[Link]
Trunked base Development
Pros Cons

● Foster perfectly DevOps / Unit testing best ● You need kind of a senior team to pull this
practices. off. You have to know how to slice a
● Enhances collaboration. feature so you can integrate regularly. Also
● As we have almost no branches, less it fosters autonomy, which can be
chance of merge conflicts. overwhelming for juniors.
● Allows quick releases ● A strong sense of CI/CD with useful testing
is a must otherwise your trunk branch can
become unstable.

[Link]
Feature Branching

[Link]
Feature Branching Pros
● Relatively simple workflow
● Supports concurrent feature development
● Single merge point
● Provides basic traceability
● Enables feature testing
Feature Branching Cons
● Scale is limited
● Limited number of contributors
● Potentially difficult merge conflicts
● Robust CI/CD is needed to realize full benefit
 Branching Strategies
Product type and its release method Team size Collaboration maturity Branching Strategies

All Small High ● Trunk Based

Products that support continuous deployment and Middle Moderate ● GitHub Flow
release, such as SaaS products

Products with a definite release window and a periodic Middle Moderate ● Git Flow
version release cadence, such as iOS apps ● GitLab Flow with
Release Branches

Products that are demanding for product quality and Middle Moderate ● GitLab Flow with
support continuous deployment and release, such as Environment
basic platform products Branches

Products that are demanding for product quality and Large Moderate ● Git Flow
have a long maintenance cycle for released versions,
such as 2B basic platform products

[Link]
GitLab Flow - Principles
● Create a new branch for the issue and periodically push a branch of the
same name on the server
● When the task is finished, push to server and request a Merge Request for
the main branch
● When the submitted changes were reviewed/approved, merge them with the
main branch
● When being merged into the main, delete the branch where the task was
developed leaving the repository more organized.

[Link]
GitLab Flow
● Feature-driven development
● Feature branching with issue tracking
Demo1 (1)
1. create new project
2. create gitignore file
3. create long live branch
a. staging
b. production
4. create feature short live branch
a. feature-a
b. feature-b
5. feature-a create 2 commit
6. feature-b create 2 commit
7. feature-a rebase to main with squash and delete branch
8. create feature short live branch
a. feature-c
9. feature-c create 2 commit
Demo1 (2)
10. feature-b rebase to main with squash and delete branch
11. staging rebase to main
12. feature-c rebase to main with squash and delete branch
13. production rebase to staging
14. tag v1.0.0
15. staging rebase to main
16. production rebase to staging
17. tag v2.0.0
Demo2 (1)
1. james: create new project and add gitignore file
2. james: create branch from main
a. production
b. staging
3. james: setting
a. Repository => Protected branches
i. Branch
1. production
2. staging
ii. Allowed to merge => Maintainers
iii. Allowed to push and merge => No one
iv. Branch => main => Allowed to push => No one
b. Merge requests
i. Merge method => Fast-forward merge
4. Project information => Members
a. Select a role => Developer
Demo2 (2)
5. bond: clone project
6. james: create new issue 1
a. feature a
7. bond: glab cli and gitlab extension
8. bond: glab issue list and view
9. bond: create feature branch a
10. bond: 1-feature-a create 2 commit
11. james: create new issue 1
a. feature b
12. bond: glab issue list and view
13. bond: create feature branch b
14. bond: 2-feature-b create 2 commit
Demo2 (3)
15. bond: push 1-feature-a
16. bond: create merge request (MR)
17. james: review merge request and merge
18. bond: glab issue list
19. bond: switch to main and git pull --prune
20. bond: delete branch 1-feature-a
21. james: merge request main to staging
22. bond: push 2-feature-b
23. bond: create merge request (MR)
24. james: review merge request and merge
25. bond: switch to main and git pull --prune
26. bond: delete branch 2-feature-b
Demo2 (4)
27. james: merge request staging to production
28. james: tag v1.0.0 to production
29. james: merge request main to staging
30. james: merge request staging to production
31. james: tag v2.0.0 to production
GitLab Flow - Enhancement flow (1)
The flow starts with the main branch, the staging environment branch, and the production environment
branch. All these branches should be protected, for developers do not commit directly to them.

[Link]
GitLab Flow - Enhancement flow (2)
To start a new development demand, you must create a specific branch for this demand and periodically
perform pushes for branch of the same name to the remote repository.

[Link]
GitLab Flow - Enhancement flow (3)
Upon finalizing the demand, a Merge Request for the main is requested. A code review can be opened in
GitLab and a discussion about the change can be started

[Link]
GitLab Flow - Enhancement flow (4)
When approved, the change must be integrated into the main branch.

[Link]
GitLab Flow - Enhancement flow (5)
A merge must then be made between the main branch and the staging branch. A pipeline should be
executed to build the project and run the automated tests.

[Link]
GitLab Flow - Enhancement flow (6)
When passing in the automated tests, a merge must be done for the production branch. A pipeline
should be executed again, to run the automated tests one more time and deploy to production.

A tag must be created to mark a stable version of the system and the feature branch must be removed to
make the repository more organized.

[Link]
GitLab Flow - Hotfix flow (1)
In the event of an urgent change that cannot wait for the main to be merge in production. It is possible to
create a branch to realize the urgent task from the production branch. This would be a flow equivalent to
the "hotfix" branch of GitFlow.

[Link]
GitLab Flow - Hotfix flow (2)
Create an error correction branch from the production branch.

[Link]
GitLab Flow - Hotfix flow (2)
Push the branch to the remote repository.

[Link]
GitLab Flow - Hotfix flow (3)
Request a Merge Request for the main branch. Usually, as in the enhancement flow.

[Link]
GitLab Flow - Hotfix flow (4)
Wait for the Merge Request to be approved and the build of the main branch to pass, indicating that
there are no errors in your commit.

[Link]
GitLab Flow - Hotfix flow (5)
When automatic tests pass in the main branch, due to urgency, you should not wait for the main branch
to be merged in other environments branches. Make a merge / merge request from your feature branch to
all other branches of internal environments.

As your feature branch is the production branch with your new commit, usually just a unique commit will
be merged to the production branch. Make sure to merge these changes to all environments branches.
Or the error correction / urgent change can be lost.

Create a tag, to mark a new system version.

[Link]
GitLab Flow - Hotfix flow (6)
Only now delete the error correction branch. The enhancement branches remain in the repository and
your correction is in all environments of the system.

[Link]
GitLab Flow - Hotfix flow (7)
When the rest of the changes are completed, the improvements will be made available in production
without erasing the error correction, as it was already integrated into the main branch of the project.

A version tag with improvements is marked.

[Link]
GitLab Flow - Hotfix flow (8)
At the end of the cycle, all changes are published in production. All non-permanent branches are
deleted. The flow is finished and a new cycle begins.

[Link]
GitLab Flow - Hotfix flow (9)
Alternatively, for urgent tasks, you can use the cherry-pick command to get just a specific commit and
send it to the other system environments. So, for example, you can send only one specific commit to
production while the others are still waiting for manual tests to finish, in the staging branch.

[Link]
GitLab Flow - Hotfix flow (10)
An important thing in this flow is that commits should always be integrated from main to production.
Never in the opposite way. As said in the original GitLab flow documentation:

"This workflow, where commits only flow downstream, ensures that

everything is tested in all environments."

[Link]