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 pathmergerequest.html
More file actions
261 lines (176 loc) · 7.45 KB
/
mergerequest.html
File metadata and controls
261 lines (176 loc) · 7.45 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
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
<!DOCTYPE html>
<html>
<head>
<title>Pull Requests - 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}
.title { margin-left: 40%; padding-top: 10%; }
</style>
</head>
<body>
<textarea id="source">
class: middle
background-image: url(./assets/background-title.jpg)
.title[
# Dev CoP Presentation: Pull Requests
]
.right[]
---
## Intro
In previous DevCoP sessions we talked about moving to Git, and the point of that is to leverage branching strategies (more light weight than a centralized repository TFVC).
The November DevCoP presentation was about branching strategies.
This presentation covers how to manage the merging of these branches in your workflow thru a process called “Pull Requests”.
NOTE: "Pull Request" are also known as "Merge Request"
---
## What is a Pull Request ?
--
A “Pull Request” allows you to visualize and collaborate on the proposed changes to source code that exist as commits on a given branch.
They are a request to merge one branch into another.
They help a team establish, enforce and verify policies on all code changes.
Example: <https://gccode.ssc-spc.gc.ca/iitb-dgiit/sds/GOCWebTemplates/DotNetTemplates/merge_requests/230>
---
Example
---
## CI-CD Pipeline
The Pull Request process covers the: Execute Tests, Code Review, Approve Changes & Merge steps within the Senior Advisors recommended CI-CD pipeline flow.
<https://esdc-devcop.github.io/guides/pipelines/cicd.html>
---
## What is the goal of a Pull Request ?
.answer[
- Manage the merging of branches in your workflow.
- Changes get verified thru automation and your colleagues.
- A big part of the Pull Request is the code review.
]
---
## What is the goal of a Code Review?
The primary goal of a code review should be collaboration.
The collaboration allows the reviewer and author of the code change to learn more about the project, enabling them both to make better changes to the project in the moment and in the future.
.answer[
- Does the code make sense?
- Were multiple features combined?
- Was debugging code removed?
]
Note: Remember to stay courteous, the code is being reviewed not the person.
---
## Roles and responsibilities of Author and reviewer
### Author
--
.answer[
- The first reviewer of your code is you.
- Keep Code review short: Contains a single task. Don't mix features. <https://github.com/esdc-devcop/recommendations/blob/master/source_management/merging-review.md>
- Describe the changes in the Pull Request. Link to a task.
- New functions and conditions come with new unit tests.
- Changed functions and conditions don't affect existing unit tests.
- Complex sections of code contains comments.
]
---
### Reviewer
--
.answer[
- Review the code as soon as possible.
- When approving a merge, you are just as responsible for the changes as the Author.
- Ask for clarifications if changes are ambiguous.
- Be effective in comments, Recommend changes in a constructive manner.
- Be aware of potential design flaws
- Be aware of alternate existing functionalities that could be suggested.
]
---
## How do I keep reviews from taking up all my time?
.answer[
- Keep the changes small: If the change is too large and could have been broken apart, reject it.
- Don’t validate code : Let the pipeline do that work for you. Focus on learning what it is the author is trying to do, and check that what they did makes sense.
- Ask for more details : Don’t spend time trying to figure it out, it should be simple enough (or explained in comments) to understand in a minute or two.
]
---
### Valid "big" pull request
In some cases, “big pull requests” are inevitable but can still be time effective if the scope is limited to one goal.
Here is an example of a manageable “big pull request”, it’s about refactoring the code.
---
## Types of Merges
Once the Reviewer has approved the code changes. Anyone with the appropriate rights can merge the changes into the parent branch.
Note: Depending on the platform there might be variations.
---
### Merge Commit
Merge commits: Retains all of the commits in your branch and interleaves them with commits on the base branch.
---
### Squash and Merge
Squash and Merge: Retains the changes but omits the individual commits from history.
---
### Rebase and Merge
Rebase and Merge: This moves the entire feature branch to begin on the tip of the master branch, effectively incorporating all of the new commits in master
If you want more in depth knowledge about merge types please let us know.
You may get more details in the following link: <https://esdc-devcop.github.io/recommendations/source_management/merging-review.html>
---
## Conclusion
The use of Pull requests increases: Quality, Collaboration and Knowledge
---
class: middle, center
background-image: url(./assets/background-image.jpg)
## We are going to help!
.okay[If you want a more in-depth disscution on this, please contact us!]
---
class: middle, center
background-image: url(./assets/background-image.jpg)
## Collaborate on Slack!
We want your collaboration.
### GCDevOpsLeague
#### .okay[gcdevopsleague.slack.com] channel: "esdc-devcop"
---
class: middle, center
background-image: url(./assets/background-image.jpg)
## 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>