Why do we use git

PRO

• Open source
• Fast
• Decentralised
• Efficient
• Easy to learn

CONTRA

• Fear of branches
• Fear of merge conflicts

1. The problem

One branch fits all!

One-person linear approach

One-environment

Unreadable history

Occasional extra branches

2. The solution in theory

A set of guidelines .

You can still do everything.

Sanitised documented workflow.

No more explanation.

2.1 The environments problem

• Never ending main-branches
• Every commit ready for deployment

1 local environment + 2 remote environments 

2.2 The purpose problem

2.2.1 You want to debug something on live or staging.

2.2.2 You are working on a tricky/new feature.

2.2.3 You are fixing feedback based on staging env.

2.2.4 You are quickly fixing a tiny bug on live. 

2.2.2 You are working on a tricky/new feature

• The first secondary branch: Feature-branch!
• No unfinished work for reviewers to see.
• No interference with other developers.
• No harm in trying stuff out. 

• Always on develop
• Delete the branch after finishing
• How to push to live?

2.2.3 You are fixing feedback based on staging env.

• Controled pieces of code forming live-releases
• Release-branch!
• All the features that are included inside the release should be reviewed

2.2.3 You are fixing feedback based on staging env.

• Choose the point in time.
• Periodical back-merges.

2.2.4 You are quickly fixing a tiny bug on live. 

• The last secondary branch: hotfix-branch!
• For avoiding the entire control process.
• Only stuff that doesn't need reviewing.

2.3 So what does this all mean?

• 2 main, 3 secondary braches
• A control system for developers, reviewers en clients.
• Live will (almost) never be broken
• Clear and enlightened history for easy debugging. 

2.4 Tagging conventions

2.4 Naming conventions

Production branch: master

Development branch: develop   

Feature branch prefix: feature/

Release branch prefix: release/

Hotfix branch prefix: hotfix/

Start to Git Flow

Further reading:

nvie.com/posts/a-successful-git-branching-model/

Get a free GUI for faster learning:

sourcetreeapp.com

Questions before I procede?

3. The practical solution

BEFORE:

 - Forgotten branches

 - No clarity

 - Scary releases

 - Unclear merge conflicts

3. The practical solution

AFTER:

 - Clear history

 - Easy releases

 - Clear merge conflicts

Merge conflicts

Develop

Feature

Merge solutions

Git Flow in Drupal

Drupal 6 & 7

Staging

Live

Features

Features

Git Flow in Drupal

Drupal 8

Staging

Live

Config

manager

Config

manager

Scalable !== Fast

Full blown structure is great for big projects

No reviewer

if (FE == 1 && BE == 1)

FE = mergers

BE = branchers

If (FE > 1 || BE > 1)

Because now there is a bigger chance of people working in the same lines of code

Put it all in context

Remember the one branch fits all solution?

Git should stay in the background

Git flow is used on every scale, but is experienced as slow on small projects. 

Using Full blown Git Flow on small projects is like putting everything in features for small projects. 

Conclusion

Adapt Git Flow to your own needs.

It makes sure developers think, before they create.

There are a couple of Git workflows too choose from:

atlassian.com/git/tutorials/comparing-workflows