Git workflow

[martinhoyer]

Git workflow change to allow for easier micro/bugfix releases

Current Workflow

• main: feature branches being merged into
• fedora: branch being used for releases
  • fedora branch usage is a workaround, can be removed (linked to https://src.fedoraproject.org/rpms/tmt/pull-request/41)
  • let's call it a release branch for sake of this discussion

Options

1. Git Flow

Description

• main branch for stable releases
• develop branch for ongoing development
• Feature branches branched off develop
• Release branches branched off develop
• Hotfix branches branched off main

Pros

• Clear separation of concerns
• Supports parallel development
• Easy to manage hotfixes

Cons

• More complex than current workflow
• Requires more branches to manage

Diagram

gitGraph
   commit
   branch develop
   commit
   branch feature1
   commit
   commit
   checkout develop
   merge feature1
   branch release-1.0
   commit
   checkout main
   merge release-1.0
   branch hotfix-1.0.1
   commit
   checkout main
   merge hotfix-1.0.1
   checkout develop
   merge hotfix-1.0.1

Loading

2. Git Flow Simplified

Description

• main branch for stable releases
• develop branch for ongoing development
• Feature branches branched off develop
• Release branches created from develop when ready to release
• Hotfix branches created from main for urgent fixes

Pros

• Simpler than full Git Flow
• Maintains clear separation between stable and development code
• Supports parallel development and easy hotfixes
• Easier release management compared to GitHub Flow

Cons

• More complex than GitHub Flow or Trunk-Based Development
• Requires discipline to maintain branching structure

Diagram

gitGraph
   commit
   branch develop
   commit
   branch feature1
   commit
   checkout develop
   merge feature1
   branch release-1.0
   commit
   checkout main
   merge release-1.0
   checkout develop
   merge release-1.0
   checkout main
   branch hotfix-1.0.1
   commit
   checkout main
   merge hotfix-1.0.1
   checkout develop
   merge hotfix-1.0.1

Loading

3. GitHub Flow with Release Branches

Description

• main branch for stable code
• Feature branches branched off main
• Release branches created from main for each release
• Bugfixes applied directly to release branches and then merged back to main

Pros

• Simpler than Git Flow
• Easy to manage releases and bugfixes
• Reduces merge conflicts

Cons

• Less separation between development and production code
• May require more frequent merges to main

Diagram

gitGraph
   commit
   branch feature1
   commit
   commit
   checkout main
   merge feature1
   branch release-1.0
   commit
   checkout main
   merge release-1.0
   branch bugfix-1.0.1
   commit
   checkout release-1.0
   merge bugfix-1.0.1
   checkout main
   merge bugfix-1.0.1

Loading

4. GitHub Flow with Hotfixes

Description

• main branch for stable code
• Feature branches branched off main
• Hotfix branches created from main for urgent fixes
• Tags used to mark releases on main

Pros

• Simple and straightforward
• Continuous deployment friendly
• Easy to apply hotfixes quickly

Cons

• Less separation between releases
• May be harder to maintain multiple versions simultaneously
• Requires careful coordination for hotfixes during feature development

Diagram

gitGraph
   commit
   branch feature1
   commit
   commit
   checkout main
   merge feature1
   commit tag: "v1.0"
   branch hotfix-1.0.1
   commit
   checkout main
   merge hotfix-1.0.1
   commit tag: "v1.0.1"

Loading

5. Trunk-Based Development with Release Branches

Description

• main branch (trunk) for all development
• Short-lived feature branches, if needed
• Release branches created from main for each release
• Bugfixes applied to main and cherry-picked to release branches

Pros

• Simplest workflow
• Continuous integration friendly
• Reduces long-lived branches and merge conflicts

Cons

• Requires disciplined developers to keep main stable
• May require feature flags for incomplete features

Diagram

gitGraph
   commit
   commit
   branch release-1.0
   commit
   checkout main
   commit
   commit id: "bugfix"
   checkout release-1.0
   cherry-pick id: "bugfix"
   checkout main
   commit

Loading

Comparison Table Ordered by Complexity

Aspect	Git Flow	Git Flow Simplified	GitHub Flow with Release Branches	GitHub Flow with Hotfixes	Trunk-Based Development
Complexity	High	Medium	Medium	Low	Low
Branch Count	Many	Moderate	Few	Few	Minimal
Release Management	Dedicated branches	Dedicated branches	Dedicated branches	Tags on main	Branches or tags
Bugfix Process	Hotfix branches	Hotfix branches	Direct to release branch	Hotfix branches	Cherry-pick to release
CI/CD Friendly	Moderate	Good	Good	Excellent	Excellent
Learning Curve	Steep	Moderate	Moderate	Gentle	Gentle
Multiple Version Support	Good	Good	Good	Limited	Moderate
Development/Production Separation	Clear	Clear	Moderate	Limited	Limited

---

---

Proposal: GitHub Flow with Hotfixes

• Probably would be a least distributive change
• Focuses on latest version
• Prioritize simplicity
• Suitable for existing CI setup (?)
• High-complexity options like 'git flow' would probably not be suitable for the tmt's project size, resources and existing practices.

Comparison: GitHub Flow with Release Branches vs GitHub Flow with Hotfixes

Aspect	GitHub Flow with Release Branches	GitHub Flow with Hotfixes
Release Strategy	Separate branches for each release	Tags on main branch
Bugfix Application	Applied to specific release branch	Applied to main and tagged
Version Management	Easy to maintain multiple versions	Focuses on latest version
Deployment	Can deploy from release branches	Deploys directly from main
Hotfix Process	Create bugfix branch from release	Create hotfix branch from main
Release Finalization	Merge release branch to main	Tag main for release
Complexity	Slightly more complex	Simpler
Long-term Maintenance	Easier for long-term support	May require more careful tracking

Key Differences:

1. Release Management:

   • With Release Branches: Each release has its own branch, making it easier to manage multiple versions concurrently.
   • With Hotfixes: Releases are marked by tags on the main branch, which is simpler but may be harder to manage multiple active versions.

2. Bugfix Process:

   • With Release Branches: Bugfixes are applied to specific release branches and then merged back to main.
   • With Hotfixes: Bugfixes are applied directly to main and then tagged as a new patch version.

3. Long-term Support:

   • With Release Branches: It's easier to provide long-term support for multiple versions as each has its own branch.
   • With Hotfixes: Long-term support for older versions may be more challenging as everything is on main.

4. Deployment:

   • With Release Branches: You can deploy from specific release branches.
   • With Hotfixes: Deployment is typically done directly from the main branch.

Actions required to transition got GitHub flow with Hotfixes

• Close fedora branch
• Configure Packit to monitor main for tags
• ???

Discussion points

Release branches vs Hotfixes
Would the extra complexity of having release branches be worth for example having the ability to do LTS releases if it'll ever come up?
Any other relevant features, foreseeable requirements, that would make GH Flow with Release branches or Git Flow Simplified a better option?

[LecrisUT]

I am leaning towards "Trunk-Based Development" because:

• tmt releases are quite often so maintenance of release branches and cherry-picking is not that cumbersome
• We don't have multiple releases that we need to support so the release branches could be very minimal
• With the exception of the refactoring branches, there are not much usage for feature branches that we would need to target instead of main. The primary usage of this that I would see is when we need multiple people to work on a feature independently and make PRs on it, which doesn't really happen.

[martinhoyer]

It might be a good idea to define what a "feature branch" is. I don't think we'd want to target anything other than main/devel branch gh flow either?

[martinhoyer]

Trying in 1.36.1 (GitHub Flow with Release Branch)

Description

• main branch for stable code
• Feature branches branched off main
• Release branch (fedora)
• Bugfixes applied directly to release branch and then merged back to main

Diagram

gitGraph
   commit id: "Release "
   branch fedora
   checkout fedora 
   commit id: "Release" tag: "1.1.0" 

   checkout main
   commit
   branch release-1.2.0
   commit id: "Release 1.2.0"
   checkout main  
   merge release-1.2.0 id: "Merge Release x.y.0 into main" 
   checkout fedora
   merge main id: "Rebase fedora" tag: "1.2.0"

   checkout main
   commit

   branch release-1.2.1
   commit id: "Cherry-pick bugfixes"
   checkout fedora
   merge release-1.2.1 id: "Merge bugfix release into fedora" tag: "1.2.1"
   checkout main
   merge fedora id: "Merge to main"

Loading

(omitting feature branches for clarity)