Git helps agile teams unleash their potential. https://www.atlassian.com/

1. Git Branching for Agile Teams

2. Why use Git + agile?

3. Git helps agile teams
unleash their potential

4. Developer
How?

5. First, let’s review
two pillars of agile

6. 1
Build in narrow vertical slices

7. Waterfall: can’t release anything
until everything is ready to release
DATABASE
BACK END
FRONT END
TESTING
“big bang” launch

8. DATABASE
BACK END
FRONT END
TESTING
MVP launch
Agile: something can get released
fairly quickly

9. Modularity for the win!

10. Or to put it another way…
Potentially shippable, even
without this piece
I have a roof!

11. The modular house
may not have all its
components, but it’ll be
move-in ready first

12. Modularity enables teams
to have something testable
—and potentially shippable—
much sooner

13. 2
Make releases a non-event

14. A big bang style release
(everything at once)
means dependencies
up the wazoo

15. Look familiar?
Just a few
dependencies...

16. Do you hold everything
in a local workspace
until the entire user
story is implemented?

17. Nope

18. That would mean an
important practice for agile
teams wasn’t followed:
continuous integration

19. Continuous integration, noun:
Testing changes against the existing
code base and in-progress changes
from the team throughout the
development cycle.

20. Sure CI is
important, but…

21. Will frequent,
incremental changes
to the repo introduce
more risk?

22. YesHmm

23. But only if all those
changes are piled on
the primary code line

24. The idea is to push
changes to the repo
without de-stabilizing
the primary code line

25. That’s where Git
comes in

26. Tell me
more!
Developer

27. branching &
merging is hell
In Subversion

28. branching &
merging is easy
In Git

29. It’s all in the way
data and histories
are tracked

30. Git stores data as a
series of snapshots
(rather than changesets)

31. If SVN is a
hand-drawn map,
Git comes with
built-in GPS

32. Git uses triangulation
to figure out what the
merged version should
look like on its own

33. But enough
about the technical
underpinnings

34. Git enables a dev to
fully exploit the power
of branch-and-merge
workflows

35. Why use a branching
workflow?

36. Branching protects the
main code line, and
supports an individual
developer’s workflow

37. Atlassian devs create
a branch for each
issue they work on

38. And it’s helping us
deliver faster than
ever before

39. Keep the main line clean
Dev branches are
like an isolation
chamber

40. No half-baked code
on the main line

41. There are other
benefits, too…

42. Clarity & traceability
If it’s been merged
up, it’s ready to
release. Easy!

43. The branch-per-issue model
is the synthesis of:
“build in narrow vertical slices”
+
“make releases a non-event”

44. Branch-per-Issue
Workflow
for SaaS teams

45. The basic idea: a master
code line with several
development branches
running alongside it

46. A branch for every issue
Keep master green
feature/DEV-30
feature/DEV-45
master
Experiment on your feature branch

47. Creating a branch
feature/DEV-30
master
Check your CI system to make
sure you’re creating your dev
branch from a clean commit!

48. Break all the tests on
a branch without
disrupting teammates

49. Merge up when work is done
feature/DEV-30
master
With implementation complete, and CI passing,
merge upstream! On some teams, the product
owner acts as a “gatekeeper,” selecting branches for
merge based on what they want to release.

50. The beauty of this
branching model:

51. Code changes that are
breaking tests on a dev branch
aren’t affecting master or
impeding the team’s ability to
release from master

52. It’s easy to control what
is released to users and
what is held back

53. Now, a variation on
that model:

54. Using an Integration Branch

55. The basic idea: a shared
integration branch running
between feature branches
and the master branch

56. But what if teammates
merge incompatible
changes upstream?

57. Surprise!
feature/DEV-30
feature/DEV-45
master

58. Now master is broken

59. And that’s sad

60. Some teams avoid this
by using a shared branch
to integrate changes
during development

61. Builds fail on the
integration branch,
not the release branch

62. Using an integration branch
integration
feature/DEV-30
master
feature/DEV-45

63. Merge all clean CI runs
on the dev branch
to the integration
branch and run CI

64. If changes don’t play
well with changes made
by teammates, go back
and fix the branch

65. When implementation
is done and CI on the
integration branch is clean,
it’s ready to merge to master

66. Branch-per-Issue
Workflow
for installed app teams

67. Multiple-version support
master
v 1.2
v 1.1
feature/DEV-30

68. In this model,
master acts as an
“alpha” branch

69. Devs make branches
off of master for
new development

70. And run CI, maybe
use an integration
branch, etc.

71. Then a stable version
branch is cut just
before release time

72. Create a bugfix branch
off the release branch
and fix the problem there

73. Multiple-version support
master
v 1.2
bugfix-DEV 32
feature/DEV-30

74. Then cascade the fix
back to the stable version
branch and master

75. Incorporating Agile
Best Practices

76. Continuous Integration
& Peer Review

77. Running CI on dev branches
All active branches
are under test

78. Yes: all active
branches

79. But that can
clog the
build queue
Zzzz

80. Balance testing rigor and
resource conservation
with manually triggered
builds on dev branches

81. Triggering CI
master
v 1.2
feature/DEV-30
Developer
Automation

82. What about code reviews?

83. With Git, use pull
requests to integrate
peer review
into the workflow

84. Using pull requests
1
2
3
Create request via UI or git request-pull
Review, revise, rinse & repeat
Approve & merge

85. Additional
Considerations

86. Is “pure” continuous
integration in a
branch-per-issue
model possible?

87. Nope

88. For a CI purist,
that matters
!
For a CI pragmatist,
it doesn’t

89. But shared integration
branches and pulling
updates from master
down to dev branches
comes close to “pure”

90. And this workflow
is so powerful for
agile teams, it’s
wise to be practical

91. Here’s to easy releases,
happy developers, and
getting Git right!

92. More info
1 http://atlassian.com/git
2 @Atlassian