When you adopted Git you either researched an effective workflow or someone in your team chose it for you. Maybe you use Gitflow, maybe a lightweight master/develop system like the Bitbucket Cloud team, or maybe you have long-running maintenance branches. Done right, all these workflows can be very effective for your team. But why is the Git project itself run by e-mailing patches to an old school mailing list? Why do you hear of cool companies like Twitter use huge mono repos and embracing patch queues? To answer these questions we need to go deeper. This talk will show you the cool side of Git workflows you are probably not using. Products covered: Bitbucket

1. NICOLA PAOLUCCI • DEVELOPER ADVOCATE • ATLASSIAN • @DURDN
Popular Git workflows
You haven’t heard about

2. 22
THE SOLUTION TO EVERYTHING
git force --push

3. The Golden Bunch The Old Guard The Squashin’ aka
NO MERGES!
Same challenge, different approaches

4. We all know branching is awesome
master
HEAD
HEAD
new-feature

5. 55
MASSIVELY SUCCESSFUL WORKFLOWS
The Golden Bunch

6. Mainstream and successful workflows
Git Flow
Influential and popular
with a clear consistent
structure and process
Bitbucket Cloud Flow
Simple setup with two
main branches:
master and develop
Product Releases
To maintain older
versions with long
running maint. branches

7. Bitbucket Cloud workflow in a nutshell
mstaging
master
feature-1
feature-2
m m
release to production = merge to master
m
R H
Stable - Production
Release
Only merges

8. 88
RUN IT VIA A MAILING LIST
The Old Guard: how the Git project itself does it

9. Workflow of
Git core team
Different branching
Patches via Email
ML is the Central hub
Every code discussion happens in
public on the Git mailing list
Patches sent via email and are
discussed publicly until consensus
Branching structure is different
than the ones you may be used to

10. Workflow of
Git core team
Branches are Fluid
next and maint are reset after each
release

11. pu - proposed updates
next
master
pu
np/topic
master - used to prepare for feature release
v2.8.0
next - features in good shape
may have regressions
maint
maint - maintenance fixes after releases
m m m
Git core team branching model
m
Rm m

12. 1212
SOME TEAMS LIKE LINEAR HISTORY
The Squashin’ AKA The NO MERGES

13. When the team size grows, looking back at
past development using branches becomes
harder (not a real quote)
LUKASZ WLODARCZYK
JIRA RELEASE MANAGER, ATLASSIAN
“
”

14. feature
Squashin’ all and avoid merges onto master
staging
master
master uses fast-forward merges thus has just clean commits

15. Flat historyEasier debugging SourceTree is happy
Enforce a strict no-merges policy
A flat history may
make using git blame
and bisect easier
A flat history is easier
to read. Intermediate
commits are rare
Avoid the ui cluttering
of an endless forest of
branches

16. Squashing
You can do this now with Bitbucket Server!
Fast-forwarding
On completing a PR you can
now squash all commits down
to a single one.
If you don’t like the clutter of
merge commits you can
enforce fast-forward merges.

17. Thank you!
NICOLA PAOLUCCI • DEVELOPER ADVOCATE • ATLASSIAN • @DURDN
Tweet at me @durdn