SlideShare a Scribd company logo
1 of 34
Download to read offline
Git branching model
For efficient development

Lemİ Orhan ERGİN
Principal software engineer @ Sony




             This document is prepared for the technical talk on 14th of november, 2012 at Sony
Why
      git      Is good ?

 Cheap Local Branching
   Everything is Local
         Git is Fast
        Git is Small
     The Staging Area
        Distributed
       Any Workflow        Changed the rules
                           2,538,360 people
           GitHub          4,315,025 repositories
                           Raised $100 million on July'12
       Easy to Learn
 Git is the new standard
      Huge community
branch
separate line of work                          concepts
Public branch
A public branch is one that more than one person pulls from

Topical (feature) branch
private branch that you alone are using, and will not exposed in the public
repository

tracking branch
local branch that knows where its remote is, and that can push to and pull
from that remote
merging and
                    branching in       git
   git has changed the way developers think of merging and branching
with Git, merging and branching are extremely cheap and simple, and they are
           considered one of the core parts of your daily workflow
workflow
Version control workflow handles features, bugs and hot fixes
   on your codebase aimed to run on multiple environments
            while keeping a clean and sane history
git     For
        designing     workflows
       It is really “a tool for designing VCS workflows”
          rather than a Version Control System itself.
 Or, as Linus would say, “git is just a stupid content tracker”
Repository management in git:
Decentralized but centralized
Main branches
We consider origin/production to be the main branch where the source
code of HEAD always reflects a production-ready state.
We consider origin/Master to be the main branch where the source code
of HEAD always reflects a state with the latest delivered development
changes for the next release. Some would call this the “integration
branch”. This is where any automatic nightly builds are built from.
More Main branches
We could also consider origin/staging to be the main branch where the
source code of HEAD always reflects a state with latest code changes
and bug fixes for the staging environment.
With this logic, you can define persistent branches for each environment.
That's up your needs.
release
each time when changes are merged back into production,
      this is a new production release by definition
supporting branches
 Unlike the main branches, these branches always have a limited life time,
                  since they will be removed eventually.
Each of these branches have a specific purpose and are bound to strict rules
 as to which branches may be their originating branch and which branches
                       must be their merge targets.



                      Feature branches
                       hotFix branches
                      Release branches
ne
                                                                                                    xt
                                                                                                       -r
                                                Feature 1            Feature 2       Feature 3   Master el
                                                                                                           ea
Feature development                                                                                           se


                                                                        2
                                                    1
                                                                                                  m
                                                                                                       Feature 2 is completed and
                                                                                                       merged back t0 master

                                                                                                  m    Feature 3 is created from
                      Pull all the updates from     1                                                  master. feature 1 does not exist
                             master frequently                                                         in the new branch
                         Pull the latest updates    1                                    3
                         then resolve conflicts
                      then merge back to master
                            It's time to complete

                                                                                                       Feature 1 is completed and
                                                                                                  m    merged back t0 master
                                                            Feature 3 merges back with   3
                                                             master and gets feature 1
                                                                                         3
                                                                                                  m

                                                              Pulls updates frequently   3


                                                                                         3
                                                                                                  m
                                                                                                       Feature 3 is completed and
                                                                                                       merged back t0 master
e
                                                          as
                                                     le
                                              t-   re Master            Release             Production
Release management                         nex



                     Features are merged
                             with master               m



                                                       m


                           All features are ready      m
                               It's time to release

                                                                          r
                                                                              Start of the
                                                                              release branch

                                                                          r
                                                                              Only fixes!
                                                       m
                                                                          r

                                   Bug fixes are
                            continuously merged        m
                               back into master                           r


                                                       m

                                                                 Release is completed.               Merge release branch
                                                                   After the merge,             p    with production branch
                                                                 delete release branch               and get a new tag
e
                                                   as
                                                le
                                         t-   re Master           Hot-Fix         Production
Hot-fixes in production               nex




                                                  m




                                                  m
                                                                                      p    Hotfix branch is created
                                                                                           from production


                                                  m



                                                                    h


                                                                                           Hotfix is merged with
                                                                                      p    production branch. Get a
                          Hot fixes are merged    m       Release is completed.            new tag for the hot fix.
                           back to master too               After the merge,
                                                          delete hotfix branch
master   production



All flows in branching model




                                                     Original graph is From
                                                          “a successful git
                                                         branching model”
                                                       by Vincent Driessen
It's time to

implement
                how ?
          but
Rebase vs merge
          And The difference ın keeping the history (1)


Merging brings two lines of development together while preserving the
ancestry of each commit history.
In contrast, rebasing unifies the lines of development by re-writing changes
from the source branch so that they appear as children of the destination
branch – effectively pretending that those commits were written on top of
the destination branch all along.
rebase requires the commits on the source branch to be re-written, which
changes their content and their SHAs
Rebase vs merge
         And The difference ın keeping the history (2)


Merging is better you Only have one (or few thrusted) committer and You
don't care much about reading your history.
rebasing makes you sure that your commits go on top of the "public" branch
Rebase vs merge
And What it means in means of history writing




                                       http://blog.sourcetreeapp.com/files/2012/08/mergerebase.png
PROS
                      merge                          PROS AND CONS


1   Simple to use and understand.
2   The commits on the source branch remain separate from other branch
    commits, provided you don’t perform a fast-forward merge. (this separation can
    be useful in the case of feature branches, where you might want to take a feature and merge it
    into another branch later)
3   Existing commits on the source branch are unchanged and remain valid; it
    doesn’t matter if they’ve been shared with others.

      CONS
1   If the need to merge arises simply because multiple people are working on
    the same branch in parallel, the merges don’t serve any useful historic
    purpose and create clutter.
PROS
                       REBASE                             PROS AND CONS


1   Simplifies your history.
2   Is the most intuitive and clutter-free way to combine commits from multiple
    developers in a shared branch

      CONS
1   Slightly more complex, especially under conflict conditions. (each commit is
    rebased in order, and a conflict will interrupt the process of rebasing multiple commits.)
2   Rewriting of history has ramifications if you’ve previously pushed those
    commits elsewhere. (you may push commits you may want to rebase later (as a backup) but
    only if it’s to a remote branch that only you use. If anyone else checks out that branch and you
    later rebase it, it’s going to get very confusing.)
Golden Rule           Of rebasing




     Never ever
   rebase a branch that you pushed,
or that you pulled from another person
Rebase or merge
        Use which strategy when
Push:
 1 Don't do your work on the public branch, use feature branches
 2 When multiple developers work on a shared branch, push & rebase
   your outgoing commits to keep history cleaner
 3 To re-integrate a completed feature branch, use merge (and opt-out of
   fast-forward commits in Git)
pull:
 1 To bring a feature branch up to date with its base branch, Prefer
   rebasing your feature branch onto the latest base branch if You
   haven’t pushed this branch anywhere yet, or you know for sure that
   other people will not have checked out your feature branch
2 Otherwise, merge the latest base changes into your feature branch
Feature development
1   Pull to update your local master
2   Check out a feature branch from master
3   Do work in your feature branch, committing early and often
4   Rebase frequently to incorporate upstream changes
5   Interactive rebase (squash) your commits
6   Merge your changes with master
7   Push your changes to the upstream
1    Pull to update your local master
  git checkout master
  git pull origin master
This should never create a merge commit because we are never working directly in master.
Whenever you perform a pull, merge or rebase, make sure that you run tests directly afterwards.
2    Check out a feature branch from master
  git checkout -b feature-1185-add-commenting
check out a feature branch named with the story id and a short, descriptive title.
The id allows us to easily track this branch back to the story that spawned it. The title is there to give
us humans a little hint as to what’s in it.
tıp
                           Pull = fetch + merge
                           You may use rebase instead of merge with the pull
                           “git pull --rebase <remote branch> <local branch>”
                           “git config branch.autosetuprebase always” for pull with rebase by default




 3   Do work in your feature branch, committing early and often
 4   Rebase frequently to incorporate upstream changes
  git fetch origin master
  git rebase origin/master
Rebase against the upstream frequently to prevent your branch from diverging significantly.

Alternative:
  git checkout master
  git pull
  git checkout feature-1185-add-commenting
  git merge master
This is often done by checking master out and pulling, but this method requires extra steps as above
5   Interactive rebase (squash) your commits
We want the rebase to affect only the commits we’ve made to this branch, not the commits that exist on
the upstream. To ensure that we only deal with the “local” commits
  git rebase -i origin/master
Git will display an editor window with a list of the commits to be modified
  pick 3dcd585 Adding Comment model, migrations, spec
  pick 9f5c362 Adding Comment controller, helper, spec
  pick dcd4813 Adding Comment relationship with Post
Now we tell git what we to do. Change these lines.
  pick 3dcd585 Adding Comment model, migrations, spec
  squash 9f5c362 Adding Comment controller, helper, spec
  squash dcd4813 Adding Comment relationship with Post
Save and close the file. This will squash these commits together into one commit and present us with a
new editor window where we can give the new commit a message.
6   Merge your changes with master
  git checkout master
  git merge feature-1185-add-commenting
merge your changes back into master
7   Push your changes to the upstream
  git push origin master
push your changes to the upstream
Bug fixes
                         Same flow as feature development

1    Prefix the branch name with “bug” to help you keep track of them
2    Do work in your bugfix branch, committing early and often
3    Rebase frequently against the upstream
4    use an interactive rebase to squash all the commits together


    With a bugfix, squash the commits down into one and exactly one commit that
            completely represents that bugfix. Half of a bugfix is useless!
references
           “A successful git branching model” by Vincent Driessen
                            http://nvie.com/posts/a-successful-git-branching-model/

               “A git workflow for agile teams” by Rein Henrichs
                    http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

                      “merge or rebase” by atlassian sourcetree
                         http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/

                  “git pull --rebase by default” by dean strelau
                        http://d.strelau.net/post/47338904/git-pull-rebase-by-default

                      “a rebase workflow for git” by randy fay
                                      http://www.randyfay.com/node/91

“A DEEP DIVE INTO THE MYSTERIES OF REVISION CONTROL” by David Soria Parra
  http://blog.experimentalworks.net/2009/03/merge-vs-rebase-a-deep-dive-into-the-mysteries-of-revision-control


background
ımages
                         http://mengshuen.deviantart.com/art/Tree-Branch-72007383
                         http://www.photolizer.com/Photo%20Studies/Material/Concrete/3wall_texture_big_101123.JPG
We recommend gitımmersion.com for learning git by practicing
Emaıl:
lemiorhan@gmaıl.com

Twitter:
HTTP://www.twitter.com/lemıorhan
                                         Lemİ orhan ergİn
                                       Lemiorhan.ergin@eu.sony.com
Linkedin:
http://www.linkedin.com/in/lemiorhan

Blog:
http://www.flyingtomoon.com

                                         Information systems europe
                                          Solution delivery Istanbul

More Related Content

What's hot

A successful Git branching model
A successful Git branching model A successful Git branching model
A successful Git branching model abodeltae
 
A Git Workflow Model or Branching Strategy
A Git Workflow Model or Branching StrategyA Git Workflow Model or Branching Strategy
A Git Workflow Model or Branching StrategyVivek Parihar
 
Git - An Introduction
Git - An IntroductionGit - An Introduction
Git - An IntroductionBehzad Altaf
 
Learning git
Learning gitLearning git
Learning gitSid Anand
 
Git One Day Training Notes
Git One Day Training NotesGit One Day Training Notes
Git One Day Training Notesglen_a_smith
 
Git Tutorial For Beginners | What is Git and GitHub? | DevOps Tools | DevOps ...
Git Tutorial For Beginners | What is Git and GitHub? | DevOps Tools | DevOps ...Git Tutorial For Beginners | What is Git and GitHub? | DevOps Tools | DevOps ...
Git Tutorial For Beginners | What is Git and GitHub? | DevOps Tools | DevOps ...Simplilearn
 
Intro to git and git hub
Intro to git and git hubIntro to git and git hub
Intro to git and git hubVenkat Malladi
 
Git and GitHub
Git and GitHubGit and GitHub
Git and GitHubJames Gray
 
Git-flow workflow and pull-requests
Git-flow workflow and pull-requestsGit-flow workflow and pull-requests
Git-flow workflow and pull-requestsBartosz Kosarzycki
 
Introduction to github slideshare
Introduction to github slideshareIntroduction to github slideshare
Introduction to github slideshareRakesh Sukumar
 
Github - Git Training Slides: Foundations
Github - Git Training Slides: FoundationsGithub - Git Training Slides: Foundations
Github - Git Training Slides: FoundationsLee Hanxue
 
Case Study: Migration to GitLab (from Bitbucket) at AppsFlyer
Case Study: Migration to GitLab (from Bitbucket) at AppsFlyerCase Study: Migration to GitLab (from Bitbucket) at AppsFlyer
Case Study: Migration to GitLab (from Bitbucket) at AppsFlyerNoa Harel
 

What's hot (20)

A successful Git branching model
A successful Git branching model A successful Git branching model
A successful Git branching model
 
A Git Workflow Model or Branching Strategy
A Git Workflow Model or Branching StrategyA Git Workflow Model or Branching Strategy
A Git Workflow Model or Branching Strategy
 
Git - An Introduction
Git - An IntroductionGit - An Introduction
Git - An Introduction
 
Learning git
Learning gitLearning git
Learning git
 
GitHub Presentation
GitHub PresentationGitHub Presentation
GitHub Presentation
 
Git Branch
Git BranchGit Branch
Git Branch
 
Introduction git
Introduction gitIntroduction git
Introduction git
 
Git for beginners
Git for beginnersGit for beginners
Git for beginners
 
Git and github
Git and githubGit and github
Git and github
 
Git One Day Training Notes
Git One Day Training NotesGit One Day Training Notes
Git One Day Training Notes
 
Git Tutorial For Beginners | What is Git and GitHub? | DevOps Tools | DevOps ...
Git Tutorial For Beginners | What is Git and GitHub? | DevOps Tools | DevOps ...Git Tutorial For Beginners | What is Git and GitHub? | DevOps Tools | DevOps ...
Git Tutorial For Beginners | What is Git and GitHub? | DevOps Tools | DevOps ...
 
Intro to git and git hub
Intro to git and git hubIntro to git and git hub
Intro to git and git hub
 
Git and GitHub
Git and GitHubGit and GitHub
Git and GitHub
 
Git-flow workflow and pull-requests
Git-flow workflow and pull-requestsGit-flow workflow and pull-requests
Git-flow workflow and pull-requests
 
Introduction to Git
Introduction to GitIntroduction to Git
Introduction to Git
 
Basic Git Intro
Basic Git IntroBasic Git Intro
Basic Git Intro
 
Introduction to github slideshare
Introduction to github slideshareIntroduction to github slideshare
Introduction to github slideshare
 
Github - Git Training Slides: Foundations
Github - Git Training Slides: FoundationsGithub - Git Training Slides: Foundations
Github - Git Training Slides: Foundations
 
Git
GitGit
Git
 
Case Study: Migration to GitLab (from Bitbucket) at AppsFlyer
Case Study: Migration to GitLab (from Bitbucket) at AppsFlyerCase Study: Migration to GitLab (from Bitbucket) at AppsFlyer
Case Study: Migration to GitLab (from Bitbucket) at AppsFlyer
 

More from Lemi Orhan Ergin

Clean Software Design: The Practices to Make The Design Simple
Clean Software Design: The Practices to Make The Design SimpleClean Software Design: The Practices to Make The Design Simple
Clean Software Design: The Practices to Make The Design SimpleLemi Orhan Ergin
 
Unwritten Manual for Pair Programming
Unwritten Manual for Pair ProgrammingUnwritten Manual for Pair Programming
Unwritten Manual for Pair ProgrammingLemi Orhan Ergin
 
10 Faulty Behaviors of Code Review - Developer Summit Istanbul 2018
10 Faulty Behaviors of Code Review - Developer Summit Istanbul 201810 Faulty Behaviors of Code Review - Developer Summit Istanbul 2018
10 Faulty Behaviors of Code Review - Developer Summit Istanbul 2018Lemi Orhan Ergin
 
Yeni Nesil Yazılım Kültürü: Daha İyi Profesyoneller, Daha Kaliteli Yazılım, D...
Yeni Nesil Yazılım Kültürü: Daha İyi Profesyoneller, Daha Kaliteli Yazılım, D...Yeni Nesil Yazılım Kültürü: Daha İyi Profesyoneller, Daha Kaliteli Yazılım, D...
Yeni Nesil Yazılım Kültürü: Daha İyi Profesyoneller, Daha Kaliteli Yazılım, D...Lemi Orhan Ergin
 
Irresponsible Disclosure: Short Handbook of an Ethical Developer
Irresponsible Disclosure: Short Handbook of an Ethical DeveloperIrresponsible Disclosure: Short Handbook of an Ethical Developer
Irresponsible Disclosure: Short Handbook of an Ethical DeveloperLemi Orhan Ergin
 
Scrum Events and Artifacts in Action
Scrum Events and Artifacts in ActionScrum Events and Artifacts in Action
Scrum Events and Artifacts in ActionLemi Orhan Ergin
 
DevOps & Technical Agility: From Theory to Practice
DevOps & Technical Agility: From Theory to PracticeDevOps & Technical Agility: From Theory to Practice
DevOps & Technical Agility: From Theory to PracticeLemi Orhan Ergin
 
Fighting with Waste Driven Development - XP Days Ukraine 2017
Fighting with Waste Driven Development - XP Days Ukraine 2017Fighting with Waste Driven Development - XP Days Ukraine 2017
Fighting with Waste Driven Development - XP Days Ukraine 2017Lemi Orhan Ergin
 
Git Anti Patterns - XP Days Ukraine 2017
Git Anti Patterns - XP Days Ukraine 2017Git Anti Patterns - XP Days Ukraine 2017
Git Anti Patterns - XP Days Ukraine 2017Lemi Orhan Ergin
 
Waste Driven Development - Agile Coaching Serbia Meetup
Waste Driven Development - Agile Coaching Serbia MeetupWaste Driven Development - Agile Coaching Serbia Meetup
Waste Driven Development - Agile Coaching Serbia MeetupLemi Orhan Ergin
 
Git Anti-Patterns - Extended Version With 28 Common Anti-Patterns) - SCTurkey...
Git Anti-Patterns - Extended Version With 28 Common Anti-Patterns) - SCTurkey...Git Anti-Patterns - Extended Version With 28 Common Anti-Patterns) - SCTurkey...
Git Anti-Patterns - Extended Version With 28 Common Anti-Patterns) - SCTurkey...Lemi Orhan Ergin
 
Git Anti-Patterns: How To Mess Up With Git and Love it Again - DevoxxPL 2017
Git Anti-Patterns: How To Mess Up With Git and Love it Again - DevoxxPL 2017Git Anti-Patterns: How To Mess Up With Git and Love it Again - DevoxxPL 2017
Git Anti-Patterns: How To Mess Up With Git and Love it Again - DevoxxPL 2017Lemi Orhan Ergin
 
Yazılım Geliştirme Kültürünün Kodları: Motivasyon, Teknik Mükemmellik ve İnov...
Yazılım Geliştirme Kültürünün Kodları: Motivasyon, Teknik Mükemmellik ve İnov...Yazılım Geliştirme Kültürünün Kodları: Motivasyon, Teknik Mükemmellik ve İnov...
Yazılım Geliştirme Kültürünün Kodları: Motivasyon, Teknik Mükemmellik ve İnov...Lemi Orhan Ergin
 
Git Anti-Patterns: How To Mess Up With Git and Love it Again
Git Anti-Patterns: How To Mess Up With Git and Love it AgainGit Anti-Patterns: How To Mess Up With Git and Love it Again
Git Anti-Patterns: How To Mess Up With Git and Love it AgainLemi Orhan Ergin
 
Clean Software Design - DevNot Summit Istanbul 2017
Clean Software Design - DevNot Summit Istanbul 2017Clean Software Design - DevNot Summit Istanbul 2017
Clean Software Design - DevNot Summit Istanbul 2017Lemi Orhan Ergin
 
Test Driven Design - GDG DevFest Istanbul 2016
Test Driven Design - GDG DevFest Istanbul 2016Test Driven Design - GDG DevFest Istanbul 2016
Test Driven Design - GDG DevFest Istanbul 2016Lemi Orhan Ergin
 
Let The Elephants Leave The Room - Remove Waste in Software Development - Bos...
Let The Elephants Leave The Room - Remove Waste in Software Development - Bos...Let The Elephants Leave The Room - Remove Waste in Software Development - Bos...
Let The Elephants Leave The Room - Remove Waste in Software Development - Bos...Lemi Orhan Ergin
 
Happy Developer's Guide to the Galaxy: Thinking About Motivation of Developers
Happy Developer's Guide to the Galaxy: Thinking About Motivation of DevelopersHappy Developer's Guide to the Galaxy: Thinking About Motivation of Developers
Happy Developer's Guide to the Galaxy: Thinking About Motivation of DevelopersLemi Orhan Ergin
 
Git - Bildiğiniz Gibi Değil
Git - Bildiğiniz Gibi DeğilGit - Bildiğiniz Gibi Değil
Git - Bildiğiniz Gibi DeğilLemi Orhan Ergin
 
Code Your Agility - Tips for Boosting Technical Agility in Your Organization
Code Your Agility - Tips for Boosting Technical Agility in Your OrganizationCode Your Agility - Tips for Boosting Technical Agility in Your Organization
Code Your Agility - Tips for Boosting Technical Agility in Your OrganizationLemi Orhan Ergin
 

More from Lemi Orhan Ergin (20)

Clean Software Design: The Practices to Make The Design Simple
Clean Software Design: The Practices to Make The Design SimpleClean Software Design: The Practices to Make The Design Simple
Clean Software Design: The Practices to Make The Design Simple
 
Unwritten Manual for Pair Programming
Unwritten Manual for Pair ProgrammingUnwritten Manual for Pair Programming
Unwritten Manual for Pair Programming
 
10 Faulty Behaviors of Code Review - Developer Summit Istanbul 2018
10 Faulty Behaviors of Code Review - Developer Summit Istanbul 201810 Faulty Behaviors of Code Review - Developer Summit Istanbul 2018
10 Faulty Behaviors of Code Review - Developer Summit Istanbul 2018
 
Yeni Nesil Yazılım Kültürü: Daha İyi Profesyoneller, Daha Kaliteli Yazılım, D...
Yeni Nesil Yazılım Kültürü: Daha İyi Profesyoneller, Daha Kaliteli Yazılım, D...Yeni Nesil Yazılım Kültürü: Daha İyi Profesyoneller, Daha Kaliteli Yazılım, D...
Yeni Nesil Yazılım Kültürü: Daha İyi Profesyoneller, Daha Kaliteli Yazılım, D...
 
Irresponsible Disclosure: Short Handbook of an Ethical Developer
Irresponsible Disclosure: Short Handbook of an Ethical DeveloperIrresponsible Disclosure: Short Handbook of an Ethical Developer
Irresponsible Disclosure: Short Handbook of an Ethical Developer
 
Scrum Events and Artifacts in Action
Scrum Events and Artifacts in ActionScrum Events and Artifacts in Action
Scrum Events and Artifacts in Action
 
DevOps & Technical Agility: From Theory to Practice
DevOps & Technical Agility: From Theory to PracticeDevOps & Technical Agility: From Theory to Practice
DevOps & Technical Agility: From Theory to Practice
 
Fighting with Waste Driven Development - XP Days Ukraine 2017
Fighting with Waste Driven Development - XP Days Ukraine 2017Fighting with Waste Driven Development - XP Days Ukraine 2017
Fighting with Waste Driven Development - XP Days Ukraine 2017
 
Git Anti Patterns - XP Days Ukraine 2017
Git Anti Patterns - XP Days Ukraine 2017Git Anti Patterns - XP Days Ukraine 2017
Git Anti Patterns - XP Days Ukraine 2017
 
Waste Driven Development - Agile Coaching Serbia Meetup
Waste Driven Development - Agile Coaching Serbia MeetupWaste Driven Development - Agile Coaching Serbia Meetup
Waste Driven Development - Agile Coaching Serbia Meetup
 
Git Anti-Patterns - Extended Version With 28 Common Anti-Patterns) - SCTurkey...
Git Anti-Patterns - Extended Version With 28 Common Anti-Patterns) - SCTurkey...Git Anti-Patterns - Extended Version With 28 Common Anti-Patterns) - SCTurkey...
Git Anti-Patterns - Extended Version With 28 Common Anti-Patterns) - SCTurkey...
 
Git Anti-Patterns: How To Mess Up With Git and Love it Again - DevoxxPL 2017
Git Anti-Patterns: How To Mess Up With Git and Love it Again - DevoxxPL 2017Git Anti-Patterns: How To Mess Up With Git and Love it Again - DevoxxPL 2017
Git Anti-Patterns: How To Mess Up With Git and Love it Again - DevoxxPL 2017
 
Yazılım Geliştirme Kültürünün Kodları: Motivasyon, Teknik Mükemmellik ve İnov...
Yazılım Geliştirme Kültürünün Kodları: Motivasyon, Teknik Mükemmellik ve İnov...Yazılım Geliştirme Kültürünün Kodları: Motivasyon, Teknik Mükemmellik ve İnov...
Yazılım Geliştirme Kültürünün Kodları: Motivasyon, Teknik Mükemmellik ve İnov...
 
Git Anti-Patterns: How To Mess Up With Git and Love it Again
Git Anti-Patterns: How To Mess Up With Git and Love it AgainGit Anti-Patterns: How To Mess Up With Git and Love it Again
Git Anti-Patterns: How To Mess Up With Git and Love it Again
 
Clean Software Design - DevNot Summit Istanbul 2017
Clean Software Design - DevNot Summit Istanbul 2017Clean Software Design - DevNot Summit Istanbul 2017
Clean Software Design - DevNot Summit Istanbul 2017
 
Test Driven Design - GDG DevFest Istanbul 2016
Test Driven Design - GDG DevFest Istanbul 2016Test Driven Design - GDG DevFest Istanbul 2016
Test Driven Design - GDG DevFest Istanbul 2016
 
Let The Elephants Leave The Room - Remove Waste in Software Development - Bos...
Let The Elephants Leave The Room - Remove Waste in Software Development - Bos...Let The Elephants Leave The Room - Remove Waste in Software Development - Bos...
Let The Elephants Leave The Room - Remove Waste in Software Development - Bos...
 
Happy Developer's Guide to the Galaxy: Thinking About Motivation of Developers
Happy Developer's Guide to the Galaxy: Thinking About Motivation of DevelopersHappy Developer's Guide to the Galaxy: Thinking About Motivation of Developers
Happy Developer's Guide to the Galaxy: Thinking About Motivation of Developers
 
Git - Bildiğiniz Gibi Değil
Git - Bildiğiniz Gibi DeğilGit - Bildiğiniz Gibi Değil
Git - Bildiğiniz Gibi Değil
 
Code Your Agility - Tips for Boosting Technical Agility in Your Organization
Code Your Agility - Tips for Boosting Technical Agility in Your OrganizationCode Your Agility - Tips for Boosting Technical Agility in Your Organization
Code Your Agility - Tips for Boosting Technical Agility in Your Organization
 

Git Branching Model

  • 1. Git branching model For efficient development Lemİ Orhan ERGİN Principal software engineer @ Sony This document is prepared for the technical talk on 14th of november, 2012 at Sony
  • 2. Why git Is good ? Cheap Local Branching Everything is Local Git is Fast Git is Small The Staging Area Distributed Any Workflow Changed the rules 2,538,360 people GitHub 4,315,025 repositories Raised $100 million on July'12 Easy to Learn Git is the new standard Huge community
  • 3. branch separate line of work concepts Public branch A public branch is one that more than one person pulls from Topical (feature) branch private branch that you alone are using, and will not exposed in the public repository tracking branch local branch that knows where its remote is, and that can push to and pull from that remote
  • 4. merging and branching in git git has changed the way developers think of merging and branching with Git, merging and branching are extremely cheap and simple, and they are considered one of the core parts of your daily workflow
  • 5. workflow Version control workflow handles features, bugs and hot fixes on your codebase aimed to run on multiple environments while keeping a clean and sane history
  • 6. git For designing workflows It is really “a tool for designing VCS workflows” rather than a Version Control System itself. Or, as Linus would say, “git is just a stupid content tracker”
  • 7. Repository management in git: Decentralized but centralized
  • 8. Main branches We consider origin/production to be the main branch where the source code of HEAD always reflects a production-ready state. We consider origin/Master to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from.
  • 9. More Main branches We could also consider origin/staging to be the main branch where the source code of HEAD always reflects a state with latest code changes and bug fixes for the staging environment. With this logic, you can define persistent branches for each environment. That's up your needs.
  • 10. release each time when changes are merged back into production, this is a new production release by definition
  • 11. supporting branches Unlike the main branches, these branches always have a limited life time, since they will be removed eventually. Each of these branches have a specific purpose and are bound to strict rules as to which branches may be their originating branch and which branches must be their merge targets. Feature branches hotFix branches Release branches
  • 12. ne xt -r Feature 1 Feature 2 Feature 3 Master el ea Feature development se 2 1 m Feature 2 is completed and merged back t0 master m Feature 3 is created from Pull all the updates from 1 master. feature 1 does not exist master frequently in the new branch Pull the latest updates 1 3 then resolve conflicts then merge back to master It's time to complete Feature 1 is completed and m merged back t0 master Feature 3 merges back with 3 master and gets feature 1 3 m Pulls updates frequently 3 3 m Feature 3 is completed and merged back t0 master
  • 13. e as le t- re Master Release Production Release management nex Features are merged with master m m All features are ready m It's time to release r Start of the release branch r Only fixes! m r Bug fixes are continuously merged m back into master r m Release is completed. Merge release branch After the merge, p with production branch delete release branch and get a new tag
  • 14. e as le t- re Master Hot-Fix Production Hot-fixes in production nex m m p Hotfix branch is created from production m h Hotfix is merged with p production branch. Get a Hot fixes are merged m Release is completed. new tag for the hot fix. back to master too After the merge, delete hotfix branch
  • 15. master production All flows in branching model Original graph is From “a successful git branching model” by Vincent Driessen
  • 17. Rebase vs merge And The difference ın keeping the history (1) Merging brings two lines of development together while preserving the ancestry of each commit history. In contrast, rebasing unifies the lines of development by re-writing changes from the source branch so that they appear as children of the destination branch – effectively pretending that those commits were written on top of the destination branch all along. rebase requires the commits on the source branch to be re-written, which changes their content and their SHAs
  • 18. Rebase vs merge And The difference ın keeping the history (2) Merging is better you Only have one (or few thrusted) committer and You don't care much about reading your history. rebasing makes you sure that your commits go on top of the "public" branch
  • 19. Rebase vs merge And What it means in means of history writing http://blog.sourcetreeapp.com/files/2012/08/mergerebase.png
  • 20. PROS merge PROS AND CONS 1 Simple to use and understand. 2 The commits on the source branch remain separate from other branch commits, provided you don’t perform a fast-forward merge. (this separation can be useful in the case of feature branches, where you might want to take a feature and merge it into another branch later) 3 Existing commits on the source branch are unchanged and remain valid; it doesn’t matter if they’ve been shared with others. CONS 1 If the need to merge arises simply because multiple people are working on the same branch in parallel, the merges don’t serve any useful historic purpose and create clutter.
  • 21. PROS REBASE PROS AND CONS 1 Simplifies your history. 2 Is the most intuitive and clutter-free way to combine commits from multiple developers in a shared branch CONS 1 Slightly more complex, especially under conflict conditions. (each commit is rebased in order, and a conflict will interrupt the process of rebasing multiple commits.) 2 Rewriting of history has ramifications if you’ve previously pushed those commits elsewhere. (you may push commits you may want to rebase later (as a backup) but only if it’s to a remote branch that only you use. If anyone else checks out that branch and you later rebase it, it’s going to get very confusing.)
  • 22. Golden Rule Of rebasing Never ever rebase a branch that you pushed, or that you pulled from another person
  • 23. Rebase or merge Use which strategy when Push: 1 Don't do your work on the public branch, use feature branches 2 When multiple developers work on a shared branch, push & rebase your outgoing commits to keep history cleaner 3 To re-integrate a completed feature branch, use merge (and opt-out of fast-forward commits in Git) pull: 1 To bring a feature branch up to date with its base branch, Prefer rebasing your feature branch onto the latest base branch if You haven’t pushed this branch anywhere yet, or you know for sure that other people will not have checked out your feature branch 2 Otherwise, merge the latest base changes into your feature branch
  • 24. Feature development 1 Pull to update your local master 2 Check out a feature branch from master 3 Do work in your feature branch, committing early and often 4 Rebase frequently to incorporate upstream changes 5 Interactive rebase (squash) your commits 6 Merge your changes with master 7 Push your changes to the upstream
  • 25. 1 Pull to update your local master git checkout master git pull origin master This should never create a merge commit because we are never working directly in master. Whenever you perform a pull, merge or rebase, make sure that you run tests directly afterwards.
  • 26. 2 Check out a feature branch from master git checkout -b feature-1185-add-commenting check out a feature branch named with the story id and a short, descriptive title. The id allows us to easily track this branch back to the story that spawned it. The title is there to give us humans a little hint as to what’s in it.
  • 27. tıp Pull = fetch + merge You may use rebase instead of merge with the pull “git pull --rebase <remote branch> <local branch>” “git config branch.autosetuprebase always” for pull with rebase by default 3 Do work in your feature branch, committing early and often 4 Rebase frequently to incorporate upstream changes git fetch origin master git rebase origin/master Rebase against the upstream frequently to prevent your branch from diverging significantly. Alternative: git checkout master git pull git checkout feature-1185-add-commenting git merge master This is often done by checking master out and pulling, but this method requires extra steps as above
  • 28. 5 Interactive rebase (squash) your commits We want the rebase to affect only the commits we’ve made to this branch, not the commits that exist on the upstream. To ensure that we only deal with the “local” commits git rebase -i origin/master Git will display an editor window with a list of the commits to be modified pick 3dcd585 Adding Comment model, migrations, spec pick 9f5c362 Adding Comment controller, helper, spec pick dcd4813 Adding Comment relationship with Post Now we tell git what we to do. Change these lines. pick 3dcd585 Adding Comment model, migrations, spec squash 9f5c362 Adding Comment controller, helper, spec squash dcd4813 Adding Comment relationship with Post Save and close the file. This will squash these commits together into one commit and present us with a new editor window where we can give the new commit a message.
  • 29. 6 Merge your changes with master git checkout master git merge feature-1185-add-commenting merge your changes back into master
  • 30. 7 Push your changes to the upstream git push origin master push your changes to the upstream
  • 31. Bug fixes Same flow as feature development 1 Prefix the branch name with “bug” to help you keep track of them 2 Do work in your bugfix branch, committing early and often 3 Rebase frequently against the upstream 4 use an interactive rebase to squash all the commits together With a bugfix, squash the commits down into one and exactly one commit that completely represents that bugfix. Half of a bugfix is useless!
  • 32. references “A successful git branching model” by Vincent Driessen http://nvie.com/posts/a-successful-git-branching-model/ “A git workflow for agile teams” by Rein Henrichs http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html “merge or rebase” by atlassian sourcetree http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/ “git pull --rebase by default” by dean strelau http://d.strelau.net/post/47338904/git-pull-rebase-by-default “a rebase workflow for git” by randy fay http://www.randyfay.com/node/91 “A DEEP DIVE INTO THE MYSTERIES OF REVISION CONTROL” by David Soria Parra http://blog.experimentalworks.net/2009/03/merge-vs-rebase-a-deep-dive-into-the-mysteries-of-revision-control background ımages http://mengshuen.deviantart.com/art/Tree-Branch-72007383 http://www.photolizer.com/Photo%20Studies/Material/Concrete/3wall_texture_big_101123.JPG
  • 33. We recommend gitımmersion.com for learning git by practicing
  • 34. Emaıl: lemiorhan@gmaıl.com Twitter: HTTP://www.twitter.com/lemıorhan Lemİ orhan ergİn Lemiorhan.ergin@eu.sony.com Linkedin: http://www.linkedin.com/in/lemiorhan Blog: http://www.flyingtomoon.com Information systems europe Solution delivery Istanbul