This repository was archived by the owner on May 4, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1
Expand file tree
/
Copy pathgitflow.html
More file actions
245 lines (172 loc) · 7.7 KB
/
gitflow.html
File metadata and controls
245 lines (172 loc) · 7.7 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
<!DOCTYPE html>
<html>
<head>
<title>GitFlow - Developer's Community of Practice</title>
<meta charset="utf-8">
<!--
H2: Lato, 36px, bold
H3: Lato, 24px, bold
H4: Lato, 22px, bold
H5: Lato, 20px, bold
H6: Lato, 19px, plain text
Body: Noto sans, 20px, plain text
$wbGray: #e1e4e7;
$button-blue: #284162;
$wbGrayLight: #eaebed;
$accent-blue: #335075;
$border-red: #af3c43;
$active-blue: #243850;
$search-gray: #e0e0e0;
$profile-gray: #eaebed;
-->
<style>
@import 'https://fonts.googleapis.com/css?family=Lato|Noto+Sans&display=swap';
body { font-family: 'Lato', sans-serif; font-size: 20px;}
h1 { font-family: 'Lato', sans-serif; border-bottom: 1px solid #af3c43; font-size: 38px; font-weight:bold }
h2 { font-family: 'Lato', sans-serif; font-size: 36px; font-weight: bold }
h3 { font-family: 'Lato', sans-serif; font-size: 24px; font-weight: bold }
.remark-slide-content { background-image: url(./assets/background.jpg); background-size: cover; }
.remark-code, .remark-inline-code { font-family: 'Ubuntu Mono'; }
.whoah { color: #d3080c }
.okay { color: #278400 }
.note { color: blue}
/* .column:first-of-type {float:left}
.column:last-of-type {float:right} */
.column-first :nth-child(n), .column-last :nth-child(n) {margin-top: 0px;}
/* .column img {
max-width:50%;
height: auto;
} */
.split-6040 .column-first {width: 60%; float:left}
.split-6040 .column-last {width: 40%; float:right}
</style>
</head>
<body>
<textarea id="source">
class: middle
# Introducing GitFlow
## A branching model for Git
.right[]
---
## What Is Git Workflow??
--
Short Answer...
A Git Workflow is a recipe or recommendation for how to use Git to accomplish work in a .note[**consistent and productive manner**]. Adopting the right workflow for your team so that you collaborate better and spend less time managing version control and more time developing code.
--
What is the things to consider when it's the time to choose a workflow?
--
.answer[
- Does this workflow scale with team size?
- Is it easy to undo mistakes and errors with this workflow?
- Is collaboration important to your workflow?
- Does this workflow impose any unnecessary overhead to the team?
]
---
## Comparison of the Workflows
---
<h3>
.whoah[But remember that these workflows are designed to be guidelines rather than concrete rules!]
</h3>
---
## What Is GitFlow??
--
GitFlow is a branching model for Git, created by Vincent Driessen.
It has attracted a lot of attention because it is well suited for collaboration and scaling projects.
We have successful experiences using GitFlow cohesively with our existing release process at ESDC.
--
### Why we recommand using GitFlow??
--
- The workflow is great for a release-based software workflow as we do here in IITB.
--
- For large project as we have here, the workflow fits very well (Large Team).
--
- Branches segregated - each branch has clear purpose and flow how to work with it
--
- Confidence - at any given point of time master and release branches are stable and ready for production
--
- It enables a code freeze without preventing developers from working on the next release.
--
- Continuous processes - continuous integration and testing for develop branch, continuous deployment for master branch
---
## Standard Working Branch
--
In the diagram below, you can see the basic pattern of git flow, but while it looks like a bad subway map, it really is an easy pattern to follow.
---
## The Branches
Gitflow separates on isolated branches the code being developed and the code validated and tested. For this, it relies on the creation of several branches whose life cycle is well defined. Here is a list of branches :
--
- Master
- The master is always stable and release ready branch.
- Codebase residing in the master branch is considered to be .note[**production-ready**].
--
- Develop
- A develop branch contains latest features and fixes.
- A develop branch is always created from master and when the features are done then push it to release branch.
--
- Feature
- Feature branches are used to develop new features for the upcoming releases.
- Feature branches are created from develop and must merge into develop.
--
- Release
- Release branches support preparation of a new production release.
- A new release branch is based off develop.
- Once it's release into production, then it must be merged into master and develop.
--
- Hotfix
- hotfix branches are necessary to act immediately upon an undesired status of master
- hotfix branches are made in separate branches based off master.
- Once the hotfix is complete and released into production, then it must be merged to both develop and master
---
## Feature development
Each new feature should reside in its own branch, which can be pushed to the central repository for backup/collaboration. But, instead of branching off master, feature branches use develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should .whoah[**never**] interact directly with master.
--
The Feature branch is always created off to the latest .note[**develop**] branch and when it's done then merged back to .note[**develop**] branch.
---
## Releases
Release branches support preparation of a new production release. Once develop has acquired enough features for a release, you fork a release branch off develop. At this point—only bug fixes, documentation generation, and other release-oriented tasks should go in this branch.
--
The new release branch is created off .note[**develop**] and merged to .note[**master**] and then again to .note[**develop**] branch.
---
## Emergency releases
Maintenance or “hotfix” branches are used to quickly patch production releases. Hotfix branches are a lot like release branches and feature branches except they're based on master instead of develop. This is the only branch that should fork directly off of master. As soon as the fix is complete, it should be merged into both master and develop, and master should be tagged with an updated version number.
--
Similar to Release branch, the new hotfix branch is created off .note[**master**] and then merged to .note[**master**] and .note[**develop**].
---
## Now what's next!
- Next steps...
- Defines your requirements that you need from your flow model that will best suit your app.
- When it’s done then pick the closest flow and start using it.
- As you start using it maybe you will find issues with your workflow so do not be afraid to adapt your flow to make it work better for your project and team (Continuous Improvement)
- Last important thing… .whoah[All] of this should be done with the team’s agreement!!
---
class: middle, center
## We are going to help!
### Another Workshop!
#### .okay[DATE]
All afternoon, we are available for drop-in (online too!).
---
class: middle, center
## Collaborate on Slack!
We need your collaboration to make this a success.
### GCDevOpsLeague
#### .okay[gcdevopsleague.slack.com] channel: "esdc-devcop"
---
class: middle, center
## Questions
</textarea>
<script src="./remark-latest.min.js" type="text/javascript">
</script>
<script>
var slideshow = remark.create({
ratio: `16:9`,
countIncrementalSlides: false
});
</script>
</body>
</html>