getlatestversion

Branching in Git

Ricci Gian Mariahttp://www.codewrecks.com – http://blogs.ugidotnet.org/rgm -

http://www.getlatestversion.it/author/alkampfer/

alkampfer@nablasoft.com

@alkampfer

…

The

Basics

The key point in “branching” is: team need a

way to work on different version of

code/sources in parallel

We need branching

A branch in TFVC (or subversion) is a “smart

copy of a folder”, thus, they are cheating on us

Centralized VCS are Cheating

In Git the concept of “branch” is a first class

citizen

Git to the rescue

Pain points in centralized

VCS

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

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

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.

Embrace the change

Local Branch

With local branches no one in the

team is affected by your choice on

how to parallelize your work

Rebase vs merge (rewriting history)

Flexibility on how you can reintegrate your local

branches before making your work available to

the team

Squashing

You can commit several time in a branch, but

you can made it composed by few/single

commit before reintegration

Public branches are not automatically downloaded

When you publish a branch,

other members are unaffected,

unless they decide to start

tracking that branch

Branch per feature

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

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

Branch per feature scares

When feature are developed in

parallel, we can have problem

during merges.

Merges are usually painful.

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

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.

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

Pull requests

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

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.

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

Question

http://svy.mk/1BLujLb

Per voi sono solo 10 minuti persi, per noi è

utilissimo per poter crescere e migliorare!