Git Branching Models and Workflows

 
Git Branching Models
and Workflows
 
1
 
Kevin Scannell, David Ferry
CSCI 5030 – Principles of Software Development
Saint Louis University
St. Louis, MO 63103
 
CSCI 5030 – Principles of Software Development
 
2
 
“A Successful Git
Branching Model”
 
“A Successful Git Branching Model”
 
Git allows frictionless branching and merging
Notes branching is an advanced topics in
centralized/SVN books
Branches that live forever: master and develop
master is stable, always production ready, pushes to
master are releases by definition
develop is used to integrate completed features (where
nightly builds might happen)
Other branches: features, releases, hotfixes
 
No other branches allowed
We never branch off of a feature branch, etc.
 
CSCI 5030 – Principles of Software Development
 
3
 
“A Successful Git Branching Model”
 
Feature branches
Branch off develop and merge back to develop (or
discarded)
Almost all changes, including trivial ones, or long-lived
feature development
Release branches
Branch off develop and merge to both develop and
master.
Created in leadup to release, no new features added
once branched, just bug fixes
Hotfix branches
Branch off master and merge back to master and
develop
Quick fixes of critical bugs in master branch
 
CSCI 5030 – Principles of Software Development
 
4
 
Why is Git Branching Different?
 
Compare to the centralized approach
Branches are full, but lightweight copies
Implemented as a pointer to a commit
Centralized version control might be as heavyweight as
full source code copy
“Workspace-oriented”
Commits are “snapshots” of the entire project
Branches are copies of the entire project
Versus revision histories of specific files
Feature branches keep prototype code separate
from integration-ready code
Especially key when multiple developers are working
simultaneously
 
CSCI 5030 – Principles of Software Development
 
5
 
“A Successful Git Branching Model”
 
Devil’s Advocate:
Long-lived feature branches
Integration gets harder the longer you’re separate
Continuous integration should be gold standard
Shared remote branches
Two or three developers can go off on their own
Planned changes should be available on development
branch as soon as possible
Make releases using new branches rather than
keeping master branch special
Semantics?
 
CSCI 5030 – Principles of Software Development
 
6
 
“Distributed Git
Distributed Workflows”
 
Centralized Workflow
All developers push/pull to a single central
repository
Integration-Manager Workflow
“Project maintainer” integrates (merges)
contributions in their repository, validates them,
and pushes changes to the official repo
Very common in open source projects
Common in medium-large teams
“integration manager” could be peer reviewers
Dictator and Lieutenants Workflow
Multiple project maintainers for very large projects
 
CSCI 5030 – Principles of Software Development
 
7
 
Merging 101
 
Three important commits to every merge:
1.
The common ancestor
2.
Head of branch 1
3.
Head of branch 2
 
The goal of merging is to combine these
three snapshots of the system.
 
CSCI 5030 – Principles of Software Development
 
8
 
master
 
feature
 
HEAD
 
HEAD
 
Simple: The Fast-Forward Merge
 
If one of the two branches has no commits after the merge,
then git can implement the merge just by manipulating the
commit tree structure. This has a side effect of making the
merge “invisible.” --no-ff forces git to make a merge commit.
 
CSCI 5030 – Principles of Software Development
 
9
Before Merge
After Merge
With --no-ff
 
Typical Merge
 
When both branches have some commits
after their last common ancestor, Git
creates a new commit that reconciles
the differences between them.
Merge commit is ugly, usually a listing
of all commits made on the branch
since the common ancestor
From the point of view of the master
branch, having all the commits in the
feature branch is not helpful. Instead
“adding feature XYZ” would be useful.
Solution: rebasing
Avoids “merge commit Christmas tree”
Some teams love it, some hate it
 
CSCI 5030 – Principles of Software Development
 
10
 
master
 
feature
 
HEAD
 
HEAD
Rebasing
 
“Re-bases” the commits from one branch
on top of the commits from another branch.
 
1.
Temporarily rewind master branch
2.
Apply commits from feature branch
to common ancestor
3.
Replay commits from master branch
 
Rebasing reorganizes the commit tree
so it looks like a branch was instead a
straight-line development path.
 
CSCI 5030 – Principles of Software Development
11
 
master
 
feature
 
HEAD
 
HEAD
 
Rebasing Pitfall
 
Caution: Be careful with rebasing
“in public” with shared repositories.
 
Commits in Git are identified by
a hash of, among other things,
their ancestor. The bright red
commit 
has the same contents
as the original purple commit,
but it is not the same commit.
 
If someone else has created work with
the original commit, that node no longer
exists in the rebased timeline.
 
CSCI 5030 – Principles of Software Development
 
12
 
Squashing Commits
 
Since rebasing can “rewrite history” you can
also use it to modify previous commit logs.
 
git rebase –i HEAD~3
 
You can also split comments as well.
 
This can be used to clean up a confusing
or otherwise unfortunate commit history.
 
CSCI 5030 – Principles of Software Development
 
13
 
HEAD
 
HEAD
Before
After
Slide Note
Embed
Share

Git branching models determine how code changes are managed and integrated in software development projects. This content discusses successful branching models, emphasizing the usage of master, develop, feature, release, and hotfix branches. It also explains why Git branching is different from centralized version control systems, highlighting the benefits of lightweight branches and how feature branches aid in concurrent development. Considerations for integrating long-lived feature branches and promoting continuous integration practices are also discussed.


Uploaded on Jul 11, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. Git Branching Models and Workflows Kevin Scannell, David Ferry CSCI 5030 Principles of Software Development Saint Louis University St. Louis, MO 63103 1

  2. A Successful Git Branching Model CSCI 5030 Principles of Software Development 2

  3. A Successful Git Branching Model Git allows frictionless branching and merging Notes branching is an advanced topics in centralized/SVN books Branches that live forever: master and develop master is stable, always production ready, pushes to master are releases by definition develop is used to integrate completed features (where nightly builds might happen) Other branches: features, releases, hotfixes No other branches allowed We never branch off of a feature branch, etc. CSCI 5030 Principles of Software Development 3

  4. A Successful Git Branching Model Feature branches Branch off develop and merge back to develop (or discarded) Almost all changes, including trivial ones, or long-lived feature development Release branches Branch off develop and merge to both develop and master. Created in leadup to release, no new features added once branched, just bug fixes Hotfix branches Branch off master and merge back to master and develop Quick fixes of critical bugs in master branch CSCI 5030 Principles of Software Development 4

  5. Why is Git Branching Different? Compare to the centralized approach Branches are full, but lightweight copies Implemented as a pointer to a commit Centralized version control might be as heavyweight as full source code copy Workspace-oriented Commits are snapshots of the entire project Branches are copies of the entire project Versus revision histories of specific files Feature branches keep prototype code separate from integration-ready code Especially key when multiple developers are working simultaneously CSCI 5030 Principles of Software Development 5

  6. A Successful Git Branching Model Devil s Advocate: Long-lived feature branches Integration gets harder the longer you re separate Continuous integration should be gold standard Shared remote branches Two or three developers can go off on their own Planned changes should be available on development branch as soon as possible Make releases using new branches rather than keeping master branch special Semantics? CSCI 5030 Principles of Software Development 6

  7. Distributed Git Distributed Workflows Centralized Workflow All developers push/pull to a single central repository Integration-Manager Workflow Project maintainer integrates (merges) contributions in their repository, validates them, and pushes changes to the official repo Very common in open source projects Common in medium-large teams integration manager could be peer reviewers Dictator and Lieutenants Workflow Multiple project maintainers for very large projects CSCI 5030 Principles of Software Development 7

  8. Merging 101 Three important commits to every merge: 1. The common ancestor 2. Head of branch 1 3. Head of branch 2 The goal of merging is to combine these three snapshots of the system. HEAD HEAD feature master CSCI 5030 Principles of Software Development 8

  9. Simple: The Fast-Forward Merge If one of the two branches has no commits after the merge, then git can implement the merge just by manipulating the commit tree structure. This has a side effect of making the merge invisible. --no-ff forces git to make a merge commit. HEAD master HEAD HEAD HEAD feature feature master HEAD master After Merge With --no-ff Before Merge CSCI 5030 Principles of Software Development 9

  10. Typical Merge When both branches have some commits after their last common ancestor, Git creates a new commit that reconciles the differences between them. Merge commit is ugly, usually a listing of all commits made on the branch since the common ancestor From the point of view of the master branch, having all the commits in the feature branch is not helpful. Instead adding feature XYZ would be useful. Solution: rebasing Avoids merge commit Christmas tree Some teams love it, some hate it HEAD feature HEAD master CSCI 5030 Principles of Software Development 10

  11. Rebasing Re-bases the commits from one branch on top of the commits from another branch. 1. Temporarily rewind master branch 2. Apply commits from feature branch to common ancestor 3. Replay commits from master branch HEAD feature HEAD master Rebasing reorganizes the commit tree so it looks like a branch was instead a straight-line development path. CSCI 5030 Principles of Software Development 11

  12. Rebasing Pitfall Caution: Be careful with rebasing in public with shared repositories. Commits in Git are identified by a hash of, among other things, their ancestor. The bright red commit has the same contents as the original purple commit, but it is not the same commit. If someone else has created work with the original commit, that node no longer exists in the rebased timeline. CSCI 5030 Principles of Software Development 12

  13. Squashing Commits Before After Since rebasing can rewrite history you can also use it to modify previous commit logs. HEAD git rebase i HEAD~3 You can also split comments as well. This can be used to clean up a confusing or otherwise unfortunate commit history. HEAD CSCI 5030 Principles of Software Development 13

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#