Git branching model for efficient development.
(1) Main branches like master and development are used for new features and releases. (2) Supporting branches like bugfix and feature branches have limited lifespans. (3) The workflow handles features, bugs, and releases across environments while maintaining a clean history. Rebasing is preferred over merging for cleaner histories when working locally, while merging integrates changes for public branches.
A Git Workflow Model or Branching StrategyVivek Parihar
Git branching model or Workflow. A Git Workflow is a recipe or recommendation for how to use Git to accomplish work in a consistent and productive manner. Git workflows encourage users to leverage Git effectively and consistently. Git offers a lot of flexibility in how users manage changes. This ppt is based on The Git Flow. It was created by Vincent Driessen in 2010 and it is based in two main branches with infinite lifetime:
master — this branch contains production code. All development code is merged into master in sometime.
develop — this branch contains pre-production code. When the features are finished then they are merged into develop.
Note: slides produced from the blog post of https://nvie.com/posts/a-successful-git-branching-model/
Two days git training with labs
First day covers git basis and essential commands
Second day covers git additional command with a big lab using a git workflow
Do you know the basics of Git but wonder what all the hype is about? Do you want the ultimate control over your Git history? This tutorial will walk you through the basics of committing changes before diving into the more advanced and "dangerous" Git commands.
Git is an open source, distributed version control system used to track many different projects. You can use it to manage anything from a personal notes directory to a multi-programmer project.
This tutorial provides a short walk through of basic git commands and the Git philosophy to project management. Then we’ll dive into an exploration of the more advanced and “dangerous” Git commands. Watch as we rewrite our repository history, track bugs down to a specific commit, and untangle commits into an LKML-worthy patchset.
This slide discusses the most popular distributed version control system that is GIT and it's different commands that we need in our daily operations for project collaboration.
Git is a distributed revision control system that is widely used in the software development industry. The presentation was used in a lecture delivered in BITS-Pilani, India. The lecture served as a basic crash course on Git.
First, it sets off with a guide to install and configure git on various platforms.
Then, the basic working concepts of Git are explained.
This is followed by a detailed step-by-step guided demonstration of a sample workflow in Git.
Afterwards, Some auxillary commands that are frequently used are discussed briefly.
Finally, basic concepts of branching and merging are detailed.
The presentation ends with a few possible merge conflicts that occur in Git.
A Basic Git intro presentation for SVN long timers doing their first steps in Git.
This presentation is meant to clear up most of the basic concepts which cause confusion with developers using Git as if it was an SVN.
A Git Workflow Model or Branching StrategyVivek Parihar
Git branching model or Workflow. A Git Workflow is a recipe or recommendation for how to use Git to accomplish work in a consistent and productive manner. Git workflows encourage users to leverage Git effectively and consistently. Git offers a lot of flexibility in how users manage changes. This ppt is based on The Git Flow. It was created by Vincent Driessen in 2010 and it is based in two main branches with infinite lifetime:
master — this branch contains production code. All development code is merged into master in sometime.
develop — this branch contains pre-production code. When the features are finished then they are merged into develop.
Note: slides produced from the blog post of https://nvie.com/posts/a-successful-git-branching-model/
Two days git training with labs
First day covers git basis and essential commands
Second day covers git additional command with a big lab using a git workflow
Do you know the basics of Git but wonder what all the hype is about? Do you want the ultimate control over your Git history? This tutorial will walk you through the basics of committing changes before diving into the more advanced and "dangerous" Git commands.
Git is an open source, distributed version control system used to track many different projects. You can use it to manage anything from a personal notes directory to a multi-programmer project.
This tutorial provides a short walk through of basic git commands and the Git philosophy to project management. Then we’ll dive into an exploration of the more advanced and “dangerous” Git commands. Watch as we rewrite our repository history, track bugs down to a specific commit, and untangle commits into an LKML-worthy patchset.
This slide discusses the most popular distributed version control system that is GIT and it's different commands that we need in our daily operations for project collaboration.
Git is a distributed revision control system that is widely used in the software development industry. The presentation was used in a lecture delivered in BITS-Pilani, India. The lecture served as a basic crash course on Git.
First, it sets off with a guide to install and configure git on various platforms.
Then, the basic working concepts of Git are explained.
This is followed by a detailed step-by-step guided demonstration of a sample workflow in Git.
Afterwards, Some auxillary commands that are frequently used are discussed briefly.
Finally, basic concepts of branching and merging are detailed.
The presentation ends with a few possible merge conflicts that occur in Git.
A Basic Git intro presentation for SVN long timers doing their first steps in Git.
This presentation is meant to clear up most of the basic concepts which cause confusion with developers using Git as if it was an SVN.
Irresponsible Disclosure: Short Handbook of an Ethical DeveloperLemi Orhan Ergin
Ethics... It could be the most important and underrated topic in software industry. It is directly related with professionalism, craftsmanship and professional discipline. From time to time we have to jump into the discussions, however we never discuss it deeper.
I have found himself in a huge blast of discussions when he tweeted about a **HUGE** security issue at the most popular operating system. Then I had deep thoughts about ethics and the behaviours of ethical developers.
In this session I talk about the followings:
* I refer to real-life stories of many good practices for professional ethics that are critical in the software development world.
* I mention technical and non-technical aspects of being an ethical developer.
* I deep dive into the arguments against the ethical controversies and the debate over the sharing of a major error in MacOS via Twitter.
DevOps & Technical Agility: From Theory to PracticeLemi Orhan Ergin
This is the content I presented in meetups for giving brief information about Agile, Devops, Software Craftsmanship, Opertions and Continuous Delivery and their connection with each other.
Yazılım Geliştirme Kültürünün Kodları: Motivasyon, Teknik Mükemmellik ve İnov...Lemi Orhan Ergin
Bugünün acımasız rekabet ortamında hayatta kalabilmek için her şirketin bir yazılım şirketi olması gerekir. Bu çok büyük bir mücadele demek. Kaliteli yazlımcılar işe alınmalı, projeler doğru yönetilmeli ve proje teslim tarihleri belirlenmelidir. Ancak, gerçekte çok farklı bir tabloyla karşılaşıyoruz. Yüzlerce geliştiriciyle iş görüşmesi yapılıyor ancak bulunamıyor. Geliştiricilerden oluşan bir ekip oluşturulsa bile, motivasyonel sorunlar, sürekli artan teknik problemler, iletişim sorunları, inovasyon eksikliği ve işten ayrılmalar ile ediyoruz. Müşteriler, kaçırılan tarihler ve çıktının düşük kalitesi nedeniyle hayal kırıklığına uğruyor.
Her yazılım geliştirme ekibi kendi dinamiklerini yaratır. Çalışanların davranışlarıyla ekiplerin gizli dinamiklerini toplandığımızda şirketteki yazılım geliştirme kültürünü oluşturuyoruz. Bu, bir yazılım geliştirme takımının ne kadar başarılı olabileceğini tanımlayan, en önemli faktörlerden biridir.
Bu oturumda, motivasyon, teknik mükemmellik, işbirliği, yardımlaşma, yenilikçilik ve başarı sağlayan bir yazılım geliştirme kültürünün nasıl kurulacağından bahsedeceğim. Yazılım dünyasına girmiş ve ilgilenen herkes katılabilir.
Bu sunum Dinamikler 2017 Kongresinde kullanılmıştır.
Git Anti-Patterns: How To Mess Up With Git and Love it AgainLemi Orhan Ergin
Git is one of the most powerful tool in developers' toolbox. If you use it correctly, it dramatically increases productivity of developers and eliminates the waste products continuously. Developers cultivate a development culture on top Git most of the time.
It's powerful but its power is untamed. Many teams fall into several traps of misusing commands and therefore feel uncomfortable while using Git. We mess up Git history, the codebase and the whole preferred branching strategy in seconds. We use branches, merge/rebase strategies, creating commits in wrong ways. Even we never take committing paradigms into account while using Git.
As a software craftsman, I've been using Git for years and I've already educated Git to hundreds of developers in all levels. I'm so lucky; I had a chance to experience huge amount of anti-patterns in time. In this talk, I will talk about what those anti-patterns are and what should we do in order not to fall into them.
TDD is the elengant way of designing software. People scares from it so much, because software design is hard and it requires discipline. In this talk, I tried to describe what TDD is from software design perspective.
Karabük Üniversitesi Programlama Günleri 2016'da gerçekleştirdiğim Git sunumu yansılarıdır.
These are the slides of my talk at Karabuk University Programming Days 2016. The slides are in Turkish.
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”
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