Session on Branching model with Git, and main differencies between a centralized version control system like TFVC.

1. getlatestversion
Branching in Git
Ricci Gian Maria
http://www.codewrecks.com – http://blogs.ugidotnet.org/rgm -
http://www.getlatestversion.it/author/alkampfer/
alkampfer@nablasoft.com
@alkampfer
…

2. The
Basics

3. The key point in “branching” is: team need a
way to work on different version of
code/sources in parallel
We need branching

4. A branch in TFVC (or subversion) is a “smart
copy of a folder”, thus, they are cheating on us

Centralized VCS are Cheating

5. In Git the concept of “branch” is a first class
citizen
Git to the rescue

6. Pain points in
centralized
VCS

7. Folder space
Each branch is a
new folder
Each branch in centralized VCS
is a new folder.
Each folder occupy space in
client workspaces.
You need to resort to tricks for
“branch switching” (es tf get
/remap)
In Git you have a working copy and can switch
between branches with a simple command

8. Folder structure
Structure your folder
You need to plan for
Trunk/main before start
working
In some situation organization
of folders is dictated by
branching structure
In Git you have a working copy, the tool is taking
“snapshot” of content of that folder, no need for
special structures

9. The result
Resistance to branching
Team use less branching, to
minimize the pain.
When moving to Git, we have a
risk that people still fear
Branching.
If you embrace Git, but use the
same branching strategies of a
centralized VCS you are failing.

10. Embrace the
change

11. Local Branch
With local branches no one in the
team is affected by your choice on
how to parallelize your work

12. Rebase vs merge (rewriting history)
Flexibility on how you can reintegrate your local
branches before making your work available to
the team

13. Squashing
You can commit several time in a branch, but
you can made it composed by few/single
commit before reintegration

14. Public branches are not automatically downloaded
When you publish a branch,
other members are unaffected,
unless they decide to start
tracking that branch

15. Branch per
feature

16. Why Branch per feature
We want business people
decide which feature flow to
the next stage and when.
With branch per feature we
can “promote” branch reacting
to need of business people

17. Ex: Kano model
Leverage portfolio
management in
conjunction with Kano
model.
Simple TFS query to show
status of our feature and
decide when to move to
next stage of visibility

18. Branch per feature scares
When feature are developed in
parallel, we can have problem
during merges.
Merges are usually painful.

19. Monitor feature branches
In centralized VCS you should
duplicate build definitions for
Feature Branches.
For complex builds this create
some manual work to be done
each time a feature starts.
In Git a build can monitor many branches with a
single build definition

20. Reduce merge pain
The more a branch diverge
from its “parent”, the more
painful is merging back.
An usual solution is to
periodically reverse integration
from source to Feature Branch.

21. Monitor feature branches
In centralized VCS knowing if a
branch merges without conflict
is a manual process.
It is difficult to know when to
do a reverse integration to easy
merge pain
In Git you can customize a build to tell you if a
feature branch automatically merges and run a full
build merge result

22. Pull requests

23. Code review on steroids
With centralized VCS you usually
conduct a code review with patch
or similar solution (Ex. Shelveset)
To conduct a real code review, you
should create a branch where the
review can evolve.
Many hosting for Git offers the concept of pull request,
where you can ask for reintegration of a branch and have
a discussion on it

24. Pull refs
Some system (Es. GitHub)
automatically create and
maintain special refs for pull
request
This will have the same effect
of build customization, but
easier and with many
advantages.

25. Automating Feature Branches
Using Feature Branches, once
a strategy is decided, is
something that can be
automated
One of the most used strategy
is called Git Flow and is
automated even by GUI tools
like source tree

26. Question

27. http://svy.mk/1BLujLb
Per voi sono solo 10 minuti persi, per noi è
utilissimo per poter crescere e migliorare!