-
Notifications
You must be signed in to change notification settings - Fork 1
Expand file tree
/
Copy pathgit-teach.html
More file actions
427 lines (305 loc) · 11.8 KB
/
Copy pathgit-teach.html
File metadata and controls
427 lines (305 loc) · 11.8 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
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
<!DOCTYPE html>
<html>
<head>
<title>Title</title>
<meta charset="utf-8">
<style>
@import url(https://fonts.googleapis.com/css?family=Yanone+Kaffeesatz);
@import url(https://fonts.googleapis.com/css?family=Droid+Serif:400,700,400italic);
@import url(https://fonts.googleapis.com/css?family=Ubuntu+Mono:400,700,400italic);
body { font-family: 'Droid Serif'; }
h1, h2, h3 {
font-family: 'Yanone Kaffeesatz';
font-weight: normal;
}
.remark-code, .remark-inline-code {
font-family: 'Ubuntu Mono';
background-color: #F0F0F0;
color: #444;
padding-left: 0.5em;
padding-right: 0.5em;
padding-top: 0.1em;
padding-bottom: 0.1em;
}
h1 {
margin-top: 0.3em;
}
ul li {
margin-bottom: 1em;
line-height: 1.2;
}
</style>
</head>
<body>
<textarea id="source">
# Agenda
* Git in general
* Working with local and remote branches
* Note this is demo line. Branching and related best practices. This is weird rebase example.
* Rebases/Merges
* Oh well, let's go crazy and edit this one as well. Conflict resolving is fun work!
* Stashing
* .gitconfig
**ASK QUESTIONS ANYTIME**
---
# Git in general
* Distributed Version Control System
* Successor of CSV, Subversion and inspired by closed source Bitkeeper
* Easier to work with as a team than predecessors
* Originally made by Linus Torvalds to improve Linux Kernel development
* Nowadays embraced even by Microsoft
* `Github !== Git`
* Git **is not infallible**. It offloads hard problems to _you_
## Github
* SaaS-service for hosting Git repositories and related tools
* Other options: Bitbucket, Gitlab, Host your own :)
---
## What the name means:
* random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
* stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
* "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
* "goddamn idiotic truckload of sh*t": when it breaks
---
# How to start
* Get Git magically to your computer. (Ubuntu: `apt install git`, Mac: Install Xcode, Windows install Git from the official site)
* Avoid GUIs, prefer command line Git. _(exception: Use PHPStorm/VSCode for conflict resolving)._
* Sooner or later you'll face problems that force you to CLI anyway.
## Git init
* `git init` creates .git directory into your working directory => Local repository
* To create new _local_ repository:
```bash
mkdir project-folder
cd project-folder
git init
nano .gitignore
```
---
## Remote repository
* Create new repo in Github
* Push your repo to Github (don't worry too much, Github will tell you what to do):
```bash
git remote add origin git@github.com:trm42/test-repo.git
git push -u origin master
```
---
# Git clone
* Use ssh as protocol
* ssh-keygen, copy the $HOME/.ssh/id*.pub keyfile content to Github
* ^ don't add password to that key as that will hinder your workflow
* **Never send / publish the non public keyfile anywhere**
```bash
git clone git@github.com:trm42/test-repo.git [DIRECTORY TO CLONE INTO]
```
---
# Git log
* Tells the whole commit history
* `git log filename` tells what commits have touched the file
* Prettier and easier to read:
```
git log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s
%Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
```
---
# Git blame
* Does what the name says
* `git blame FILENAME`
* Who has modified the file and what lines and in what commit
---
# Git branch
* List branches and see current: `git branch`
* Make sure you're branching from right branch first: `git checkout release-candidate`
* Create Branch: `git checkout -b BRANCH_NAME`.
* Checkout a branch: `git checkout EXISTING_BRANCH_NAME`
* Pull latest changes from upstream: `git pull`
* Rename local branch : `git branch -m NEW_BRANCH_NAME`
* delete: `git branch -D DELETABLE_BRANCH_NAME`
---
# Branching strategies
* One feature per branch
* Sensible units of work
* Avoid **MEGA GODZILLA** branches
## Bigger set of features:
* Make feature set main branch. Example: `UK-2021-new-invoice-process`
* Make every feature as a separate feature/task branch, make PRs for them and merge to feature set branch
* `UK-2022-send-invoices-to-ireland`
* `UK-2023-fix-devil-signs-invoices`
* `UK-2024-revert-who-creates-these-prs-fix-this-bleeep`
---
# Branch naming
* Feature branches `UK-123-fix-brainfarts`
* Add descriptive verb after ticket number: `fix, hotfix, change, delete, add`
## Branches
* Develop === For long term development projects
* Release candidate / Staging === Last fortress before master. Deployed to staging envs
* Master === Production branch. Everything merged here gets deployed to production
---
# Git stage 1/3
* Stage of changed files
* `git status`
## Git add
* Normal usage `git add FILES OR DIRECTORIES`
* Creates SHA hash for your file
* `git add -p` goes through all changes and offers them separately to be added
* **Avoid** `git add .` Use bash completion if it makes life easier
* To take files off from stage `git reset FILES OR DIRECTORIES`
* To reset files to their pre-modified state `git checkout FILE OR DIRECTORIES`
---
# Git stage 2/3
* `Git mv OLD_FILENAME NEW_FILENAME`
* `Git rm UNNECESSARY_FILE`. Note: removes also the local version
* `git rm --cached` don't remove local version
---
# Git stage 3/3
## Git commit
* Adds your staged changes to your local version history
* Create good commit messages
* Actually describe **what** you have done and **WHY**
* `git commit` Opens defined $EDITOR for writing the commit message.
* `git commit -m "Fix brainfart und wolf because... OMAGOD WE'RE ALL GOING TO DIE"`
* `git commit -m "Fix annoying bug that breaks things In FoobarController as bars were running out " --amend` (works only before push)
* `git commit -m "short message" -m "Longer description"`
---
## Suggestions for possible commit message rules
1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how
## Short Examples
* `Move composer.json require-dev doctrine/dbal to require as it is needed in staging and prod as they do only composer install --no-dev as they are supposed to be doing`
* `Delete all validation lang files because translations are responsibility of the frontends`
* `Fixing fix of the fix of the fix`
* `Fixing brainfarty blob of blob`
---
## Long Commit Message Example
Longer read: https://chris.beams.io/posts/git-commit/
Summarize changes in around 50 characters or less
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.
Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded
by a single space, with blank lines in between, but conventions
vary here
If you use an issue tracker, put references to them at the bottom,
like this:
Resolves: #123
See also: #456, #789
---
# Git push
* Pushes changes to upstream (Github or Bitbucket repository)
* Usually straightforward when the upstream branch has been set (`git push --set-upstream origin UK-123`)
* If you're creating a new pull request, remember to go to Github and create the PR :)
* After rebase: `git push --force` so the git PR history gets back to normal
* Don't push to branches which have been already merged
# Git pull
* Usually nothing special although may induce git merge if the local and upstream has different commits
* In that case `git merge abort` may be good idea...
---
# Git diff
* `git diff -r BRANCH OR GIT COMMIT HASH`
* Diffmerge and diff-so-fancy makes life more fun <3
---
# Github workflow
* `git checkout release-candidate`
* `git pull`
* `git branch -b UK-999-remove-brainfarts`
* Lots of `git commit`s
* `git push --set-upstream origin UK-999-remove-brainfarts`
* Head to Github and create pull request
* Pester others until they make CRs
* Fix CR stuff
* Commit and Push
* Wait for approval
* (rebase + push --force if needed)
* Merge to RC (Deployment to Staging etc)
* RC gets merged to Master (Deployment to Production)
---
# Pull Requests and Code Reviews
* Branch -> Pull Request -> Code Review -> Fix -> Code Review -> Merge
* _Everybody's_ code needs to be reviewed
* Everybody needs to do code reviews. It doesn't belong Somebody Else's Problem field
* Functions as QA Sanity check
* Two pairs of fresh eyes finds funny things <3
* Accidental Errors
* Structural Errors
* Distributes knowledge about what has been done and why
* Makes codebase more consistent
* Reviewers can learn new
* Shorter PRs are easier to review
* Take your time
---
## Things to note when doing CR
* Does the code do what task defines?
* Is there something to refactor or abstract?
* Possible security or privacy implications
* Does the code reimplement already existing functionality?
* Best Practices?
* No commented code
* Is there a possibility of unintentended and undocumented breaking change?
---
## Keywords for CR:
* Suggestion
* Fix
* Question
More about Code review best practices https://medium.com/palantir/code-review-best-practices-19e02780015f
---
# Merge vs Rebase?
https://www.atlassian.com/git/tutorials/merging-vs-rebasing
* Merging is non-destructive. Just a new merge commit down the line
## Merge
* Good for merging branches into mainline. That's how Github does it
* Bad for keeping Git log understandable in the long run
---
## Rebase
* Old commits are put below the new commits -> linear commit log
* Not for public branches (master, release candidate) without coordination
* Requires force push
* If working in a branch for more than one day, one should rebase the branch quite often when starting the work, helps to see possible problems earlier
* Git rerere (if you need to resolve same stuff multiple times, this is a life saver <3 )
* `git rebase origin/release-candidate`
* `git rebase --continue`
* `git rebase --skip`
* `git rebase --abort`
* **Remember to do** `git push --force-with-lease` after rebase
* Rebase order matters. UK-114 -> UK->113 -> UK->82 -> Release Candidate
---
## Conflict resolve
* PHPStorm's conflict resolve is awesome. Use that.
* Automatic resolve is good for most changes, concentrate on conflicts.
---
# Git cherry-pick
* *Sometimes* it's easier to pick 1-2 commits from another branch to another
* `git cherry-pick COMMIT HASH`
* **Don't try to use it on bigger things**. Easy to mess up things!
---
# Git stash
* Helps with uncommitted work when you don't want to commit them yet but need to change branch temporarily
* Literally stashes your work away
* `git stash`
* `git stash list`
* `git stash apply STASH_NUMBER`
---
# GURU Stuff
* ~/.gitconfig (shortcuts, rerere)
* https://github.com/so-fancy/diff-so-fancy
* https://github.com/michaeldfallen/git-radar
* https://www.youtube.com/watch?v=duqBHik7nRo
</textarea>
<script src="https://remarkjs.com/downloads/remark-latest.min.js">
</script>
<script>
var slideshow = remark.create();
</script>
</body>
</html>