summaryrefslogtreecommitdiff
path: root/reveal.js/git.html
diff options
context:
space:
mode:
Diffstat (limited to 'reveal.js/git.html')
-rwxr-xr-xreveal.js/git.html513
1 files changed, 513 insertions, 0 deletions
diff --git a/reveal.js/git.html b/reveal.js/git.html
new file mode 100755
index 0000000..6ee3406
--- /dev/null
+++ b/reveal.js/git.html
@@ -0,0 +1,513 @@
1<!doctype html>
2<html lang="en">
3 <head>
4 <meta charset="utf-8">
5 <title>Introduction to git</title>
6 <meta name="author" content="Simeon Simeonov">
7 <meta name="apple-mobile-web-app-capable" content="yes">
8 <meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">
9 <meta name="viewport" content="width=device-width, initial-scale=1.0">
10
11 <link rel="stylesheet" href="dist/reset.css">
12 <link rel="stylesheet" href="dist/reveal.css">
13
14 <link rel="stylesheet" href="dist/theme/statnett.css" id="theme">
15
16 <!-- Theme used for syntax highlighting of code -->
17 <link rel="stylesheet" href="plugin/highlight/monokai.css" id="highlight-theme">
18 <!-- <link rel="stylesheet" href="plugin/highlight/zenburn.css" id="highlight-theme"> -->
19 </head>
20 <body>
21 <div class="reveal">
22
23 <!-- Any section element inside of this container is displayed as a slide -->
24 <div class="slides">
25
26 <section>
27 <h2>Introduction to Git</h2>
28 </br>
29 <p>Competence group (Faggruppe) Python</p>
30 <p><small>Simeon Simeonov - TDE</small></p>
31 </section>
32
33 <section>
34
35 <section id="fragments">
36 <h2>Agenda</h2>
37 </br>
38 <ul>
39 <span class="fragment"><li>What is Git? A brief history</li></span>
40 <span class="fragment"><li>Working locally. Dealing with commits and branches</li></span>
41 <span class="fragment"><li>Using remotes and GitLab</li></span>
42 <span class="fragment"><li>Walkthrough. Demonstrating some common Git flows</li></span>
43 </ul>
44 </section>
45
46 </section>
47
48
49 <section>
50 <h2>What is Git?</h2>
51 <p>Git is a <em>distributed version control</em> system that tracks changes in any set of computer files, usually used for coordinating work among programmers who are collaboratively developing source code during software development.</p>
52 <p><em>Distributed version control</em> is a form of version control in which the complete codebase, including its full history, is mirrored on every developer's computer.</p>
53 <ul>
54 <span><li>Git development was started by Linus Torvalds on 3. April 2005</li></span>
55 <span><li>Torvalds wanted a distributed system that he could use like <em>BitKeeper</em>, but none of the available free (as in freedom) systems met his needs</li></span>
56 <span><li>The main objectives were: performance, very strong safeguards against corruption, either accidental or malicious, distributed workflow</li></span>
57 <span><li>The name: <em>git</em> means "unpleasant person" in British English slang. "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'.". The man page describes Git as "the stupid content tracker".</li></span>
58 <span><li>Torvalds achieved his performance goals on 29 April 2005</li></span>
59 <span><li>Torvalds turned over maintenance on 26 July 2005 to Junio Hamano, a major contributor to the project. Hamano was responsible for the 1.0 release on 21 December 2005</li></span>
60 <span><li>Current (23. February 2024) stable version: 2.44.0</li></span>
61 </ul>
62 </section>
63
64
65 <section>
66 <h2>Configuring Git</h2>
67 </br>
68 <p>We start be configuring Git for our needs</p>
69 <ul>
70 <span><li><em>git config</em> - gets and sets repository options</li></span>
71 <span><li><em>git config --global</em> - gets and sets global options</li></span>
72 </ul>
73
74 <p>Using WSL / devbox or Git for Windows (from <em>Software Center</em>):</p>
75 <pre data-id="code-animation">
76 <code class="bash" data-trim type="text/template">
77 # - this is a comment and the remainder of this line will be ignored by the shell
78 git config --global user.name "Simeon Simeonov"
79 git config --global user.email "simeon.simeonov@statnett.no"
80 git config --global init.defaultBranch master # sets 'master' as the default branch name
81 # git config --global init.defaultBranch main # sets 'main' as the default branch name
82 </code>
83 </pre>
84 <p><b>Note: </b>The recommended name for the default branch is 'main'</p>
85 </section>
86
87
88 <section>
89 <h2>The Git repository</h2>
90 </br>
91 <p>A Git repository is a virtual storage of your project. It allows you to save versions of your code, which you can access when needed.</p>
92 <ul>
93 <span><li><em>git init</em> - creates an empty Git repository or reinitializes an existing. A new .git subdirectory is created in your current working directory. This will also create a new <em>master</em> branch.</li></span>
94 <span><li><em>git add</em> - add file contents to the index - a file or directory (folder) contents are selected to be <em>tracked</em></li></span>
95 </ul>
96 <pre data-id="code-animation">
97 <code class="bash" data-trim type="text/template">
98 mkdir myproject # creates a new folder named 'myproject'
99 cd myproject # sets 'myproject' as current working directory
100 touch README.md pycode.py # creates the empty files 'README.md' and 'pycode.py' in the new folder
101 git init # creates an empty Git repository inside 'myproject' - a .git folder is added
102 git add README.md pycode.py # selects 'README.md' and 'pycode.py' for tracking
103 </code>
104 </pre>
105 </section>
106
107
108 <section>
109 <h2>Tracking content</h2>
110 </br>
111 <ul>
112 <span><li><em>git status</em> - shows the working tree status</li></span>
113 </ul>
114 <p>Each file in your working directory can be in one of two states:</p>
115 <ul>
116 <span><li><em>tracked</em> - the files Git knows and "cares" about - files that were in the last snapshot, as well as any newly staged files. They can be <em>unmodified</em>, <em>modified</em>, or <em>staged</em>.</li></span>
117 <span><li><em>untracked</em> - files that Git doesn't "care" about</li></span>
118 </ul>
119 <p>Often, you'll have a class of files that you don't want Git to automatically add or even show you as being untracked. These are generally automatically generated files such as log files or files produced by your build system. In such cases, you can create a file listing patterns to match them named <em>.gitignore</em>. Here is an example <em>.gitignore</em> file:</p>
120 <pre data-id="code-animation">
121 <code class="bash" data-trim type="text/template">
122 cat .gitignore
123 *.pyc
124 *~
125 </code>
126 </pre>
127 </section>
128
129
130 <section>
131 <h2>Committing changes</h2>
132 </br>
133 <p>A <em>commit</em> command captures a snapshot of the project's currently staged changes. Committed snapshots can be thought of as "safe" versions of a project. A snapshot can be seen as a "node" (with an unique id) related to the previous commit (unless initial commit)</p>
134 <ul>
135 <span><li><em>git commit</em> - records changes to the repository</li></span>
136 </ul>
137 <img src="images/git/commit.png"></img>
138 <p>Any files you have created or modified that you haven't run <em>git add</em> on since you edited them - won't go into this commit. They will stay as modified files on your disk.</p>
139 </section>
140
141
142 <section>
143 <h2>Committing changes (cont.)</h2>
144 </br>
145 <ul>
146 <span><li><em>git diff</em> - shows changes between commits, commit and working tree, etc</li></span>
147 <span><li><em>git log</em> - shows commit logs</li></span>
148 <span><li><em>git show</em> - shows various types of objects</li></span>
149 <span><li><em>git tag</em> - creates, lists, deletes or verifies a tag object</li></span>
150 </ul>
151 <pre data-id="code-animation">
152 <code class="bash" data-trim type="text/template">
153 cd myproject
154 echo "# My project documentation" > README.md # sets a basic content for the file README.md
155 echo "import os" >> pycode.py # appends a new content to the file pycode.py
156 git add README.md pycode.py # stages the changes
157 git commit -m "Initial commit" # creates a commit with commit message
158 # git commit -a -m "Initial commit" # automatically stages files that have been modified
159 git log # shows the existing commits (only one so far)
160 echo "import sys" >> pycode.py # appends a new line to 'pycode.py'
161 git status # shows that one file - 'pycode.py' has been modified since the last commit
162 git diff # shows that changes for this repository
163 git diff pycode.py # shows the changes for a particular file
164 git commit -a -m "Import the sys module" # stages and commits the last changes
165 git tag v0.1 # creates a lightweight tag 'v0.1'
166 git log # shows that a new commit has been added
167 git show &lt;commit id&gt; # shows the files and their changes that are part of a given commit
168 </code>
169 </pre>
170 </section>
171
172
173 <section>
174 <h2>Undoing things</h2>
175 </br>
176 <ul>
177 <span><li><em>git restore</em> - restores working tree files (Git version >= 2.23.0)</li></span>
178 </ul>
179 <pre data-id="code-animation">
180 <code class="bash" data-trim type="text/template">
181 cd myproject
182 touch newpycode.py # creates a new file
183 git add newpycode.py # sets the file as tracked (and stages it)
184 echo "import sys" >> pycode.py # appends yet another new line
185 echo "The new project documentation is here" >> README.md # appends yet another new line
186 git add README.md # stages README.md
187 git status # shows 'newpycode.py' (new file), 'pycode.py' (modified), 'README.md' (modified and staged)
188
189 git restore --staged newpycode.py # 'newpycode.py' now becomes untracked
190 # git reset HEAD newpycode.py # Git version < 2.23.0
191
192 git restore --staged README.md # unstages 'README.md' (modified)
193 # git reset HEAD README.md # Git version < 2.23.0
194
195 git restore pycode.py # reverts all modifications on 'pycode.py'
196 # git checkout -- pycode.py # Git version < 2.23.0
197 </code>
198 </pre>
199 </section>
200
201
202 <section>
203 <h2>Git branching</h2>
204 <p>Branching means you diverge from the main line of development and continue to do work without messing with that main line. Some people refer to the Git branching model as its "killer feature", and it certainly sets Git apart in the VCS community. The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop.</p>
205 <img style="width: 40vw;" src="images/git/branches.png"></img>
206 </section>
207
208
209 <section>
210 <h2>Git branching (cont.)</h2>
211 </br>
212 <ul>
213 <span><li><em>git branch</em> - lists, creates, or deletes branches</li></span>
214 <span><li><em>git checkout</em> - switches branches or restores working tree files</li></span>
215 </ul>
216 <pre data-id="code-animation">
217 <code class="bash" data-trim type="text/template">
218 git branch testing # creates a new branch from 'master' called 'testing'
219 </code>
220 </pre>
221 <img style="width: 40vw;" src="images/git/head-to-master.png"></img>
222 </section>
223
224
225 <section>
226 <h2>Git branching (cont.)</h2>
227 </br>
228 <pre data-id="code-animation">
229 <code class="bash" data-trim type="text/template">
230 git checkout testing # makes 'testing' testing the current (active) branch
231 # git checkout -b testing # creates a new branch named 'testing' and makes it active
232 </code>
233 </pre>
234 <img style="width: 45vw;" src="images/git/head-to-testing.png"></img>
235 </section>
236
237
238 <section>
239 <h2>Git branching (cont.)</h2>
240 </br>
241 <pre data-id="code-animation">
242 <code class="bash" data-trim type="text/template">
243 echo "Extra content" >> README.md
244 git commit -a -m "Improve the documentation" # creates a new commit on the 'testing' branch
245 </code>
246 </pre>
247 <img style="width: 45vw;" src="images/git/advance-testing.png"></img>
248 </section>
249
250
251 <section>
252 <h2>Git branching (cont.)</h2>
253 </br>
254 <pre data-id="code-animation">
255 <code class="bash" data-trim type="text/template">
256 git checkout master # "switches" to 'master'
257 </code>
258 </pre>
259 <img style="width: 45vw;" src="images/git/checkout-master.png"></img>
260 </section>
261
262
263 <section>
264 <h2>Git branching (cont.)</h2>
265 </br>
266 <pre data-id="code-animation">
267 <code class="bash" data-trim type="text/template">
268 echo "# Extra comment" >> pycode.py
269 git commit -a -m "Add a very useful comment to the Python code" # creates a new commit on the 'master' branch
270 </code>
271 </pre>
272 <img style="width: 45vw;" src="images/git/advance-master.png"></img>
273 </section>
274
275
276 <section>
277 <h2>Merging</h2>
278 <p>In Git, there are two main ways to integrate changes from one branch into another: the <em>merge</em> and the <em>rebase</em></p>
279 <ul>
280 <span><li><em>git merge</em> - joins two or more development histories together</li></span>
281 </ul>
282 <p>There are three possible outcomes when attempting to merge two different branches:</p>
283 <ul>
284 <span><li><em>fast forward</em> - the last common node between the source and the target branch is also the last node on the target branch (no changes since the source branch branched out). The changes (the commits) on the source branch are simply appended to the target branch. No new commits are created.</li></span>
285 <span><li><em>merge commit</em> - both the source and the target branch have new commits after the last common node. A new commit node is created on the target branch</li></span>
286 <span><li><em>conflict</em> - both the source and the target branch have new commits after the last common node. At least one file has been edited differently on both branches. A three-way-merge is performed resulting in a new commit node is created on the target branch</li></span>
287 </ul>
288 </section>
289
290
291 <section>
292 <h2>Rebasing</h2>
293 <p>With the <em>rebase</em> command, you can take all the changes that were committed on one branch and replay them on a different branch.</p>
294 <ul>
295 <span><li><em>git rebase</em> - reapply commits on top of another base tip</li></span>
296 </ul>
297 <p>The following is a typical situation when dealing with two diverged branches. A new merge commit (C5) is created when using merge:</p>
298 <pre data-id="code-animation">
299 <code class="bash" data-trim type="text/template">
300 git checkout master
301 git merge experiment # merges 'experiment' into 'master'
302 </code>
303 </pre>
304 <img style="width: 45vw;" src="images/git/basic-rebase-2.png"></img>
305 </section>
306
307
308 <section>
309 <h2>Rebasing (cont.)</h2>
310 <pre data-id="code-animation">
311 <code class="bash" data-trim type="text/template">
312 git checkout experiment # Note!! (not master)
313 git rebase master
314 </code>
315 </pre>
316 <img style="width: 45vw;" src="images/git/basic-rebase-3.png"></img>
317 <p>...now the following operation will result in a fast-forward merge:</p>
318 <pre data-id="code-animation">
319 <code class="bash" data-trim type="text/template">
320 git checkout master
321 git merge experiment
322 </code>
323 </pre>
324 <p><b>N.B. Do not rebase commits that exist outside your repository and that people may have based work on!</b></p>
325 </section>
326
327
328 <section>
329 <h2>Remotes</h2>
330 </br>
331 <p>To be able to collaborate on any Git project, you need to know how to manage your remote repositories. Remote repositories are versions of your project that are hosted on the Internet or network somewhere. Locally a remote can be seen as a sort of bookmark.</p>
332 <ul>
333 <span><li><em>git remote</em> - manages set of tracked repositories (remotes)</li></span>
334 <span><li><em>git clone</em> - clones a repository into a new directory. A remote named "origin" will be automatically created</li></span>
335 <span><li><em>git fetch</em> - downloads objects and refs from another repository</li></span>
336 <span><li><em>git pull</em> - fetches from and integrates with another repository or a local branch</li></span>
337 <span><li><em>git push</em> - updates remote refs along with associated objects</li></span>
338 </ul>
339 <p>The two most popular protocols (schema) for interacting with remotes are <em>ssh</em> and <em>http(s)</em> (usually read-only)</p>
340 </section>
341
342
343 <section>
344 <h2>GitLab</h2>
345 </br>
346 <p><em>GitLab</em> is a developer platform that allows developers to create, store, manage and share their code. It uses Git, providing the distributed version control of Git plus access control, bug tracking, software feature requests, task management, continuous integration...</p>
347 <p>Statnett operates its own instance at <a href="https://gitlab.statnett.no">https://gitlab.statnett.no</a>. It is used for storing / managing Statnett's own Git repositories</p>
348 <p>Another popular and widely used platform is <a href="https://github.com">GitHub - https://github.com</a></p>
349 </section>
350
351
352 <section>
353 <h2>Walkthrough</h2>
354 </br>
355 <p>The following walkthrough illustrates some of the most common patterns when two or more parties are using Git and GitLab in a typical project at Statnett.</p>
356 <p><b>Note: </b>GitLab's CI/CD will not be included in this presentation.</p>
357 <p><b>Note: </b>This presentation should not be considered as a reference but merely as an introduction.</p>
358 </section>
359
360
361 <section>
362 <h2>Walkthrough - Accessing GitLab</h2>
363 </br>
364 <p>In order for a local repository to be able to interact with GitLab through the SSH protocol, a private / public SSH key pair has to be created</p>
365 <pre data-id="code-animation">
366 <code class="bash" data-trim type="text/template">
367 ssh-keygen -t ed25519 # interactively creates a key pair in ~/.ssh
368 cat ~/.ssh/id_ed25519.pub # displays the public key
369 </code>
370 </pre>
371 <p>The public key is then added (pasted) under <em>User settings -> SSH Keys -> Add new key</em></p>
372 </section>
373
374
375 <section>
376 <h2>Walkthrough - Initial code / repository</h2>
377 </br>
378 <p>When starting a new repository that is about to be shared using GitLab, a corresponding GitLab project is created first. Then there are two possible approaches.</p>
379 <ul>
380 <span><li>a new repository is created on GitLab and then cloned (<em>git clone</em>) by all other parties</li></span>
381 <span><li>the repository is initialized locally and then pushed (<em>git push</em>) to GitLab</li></span>
382 </ul>
383 <pre data-id="code-animation">
384 <code class="bash" data-trim type="text/template">
385 git clone &lt;url&gt; # clones (copies) the repository
386
387 git remote add origin &lt;url&gt; # adds a new remote in the local repository
388 git push origin main
389 </code>
390 </pre>
391 <p>All parties should have a local copy of the same repository. For this demonstration we can imagine two users, randomly called "Daniel" and "Simeon".</p>
392 </section>
393
394
395 <section>
396 <h2>Walkthrough - A very simple flow</h2>
397 </br>
398 <p>Usually changes should not be committed directly into the main branch. Daniel starts by creating a new branch from "main" called "feature1"</p>
399 <p>He commits his changes there and pushes them to the remote (origin) branch "feature1". He then creates a merge request (MR) (also known as a pull request on GitHub) to the main branch on the remote origin</p>
400 <pre data-id="code-animation">
401 <code class="bash" data-trim type="text/template">
402 git checkout main
403 git checkout -b feature1
404 # editing some code
405 git commit -a -m "Add a new function"
406 git push origin feature1
407 # MR is created and reviewed by Simeon. "feature1" is then merged into "main"
408 git checkout main
409 git pull origin main # done before the next time we want to branch out from "main"
410 </code>
411 </pre>
412 </section>
413
414
415 <section>
416 <h2>Walkthrough - A more complex flow using rebase</h2>
417 </br>
418 <p>Simeon starts by updating his local main branch. He then branches out from "main" to a branch called "interesting". He commits his changes there.</p>
419 <p>At the same time Daniel branches out to "moreinteresting" and commits changes (to a different file).Daniel pushes his changes to origin "moreinteresting" and then using MR to origin "main".</p>
420 <p>The next day Simeon rebases "main" onto his "interesting". Finally Simeon creates his own MR after pushing his "intersting" branch to origin interesting</p>
421 <pre data-id="code-animation">
422 <code class="bash" data-trim type="text/template">
423 git checkout main # both Simeon and Daniel
424 git checkout -b interesting # Simeon
425 git checkout -b moreinteresting # Daniel
426 # editing some code
427 git commit -a -m "Add a new interesting feature" # Simeon
428 git commit -a -m "Add a new even more interesting feature" # Daniel
429 git push origin moreinteresting # Daniel
430
431 # The next day (Simeon)
432 git fetch origin # the current branch is still "interesting"
433 git rebase origin/main
434 git push origin interesting
435 # creates a MR
436 git pull origin main # done before the next time we want to branch out from "main"
437 </code>
438 </pre>
439 </section>
440
441
442 <section>
443 <h2>Walkthrough - Squahing commits</h2>
444 </br>
445 <p>The act of "squashing" your commits means that you combine multiple existing commits into a single one. If you should do this or avoid it is - to some extent - a question of preference: in some teams, for example, squashing commits is the preferred way to merge a feature branch back into a long-running branch like "master" or "main".</p>
446 <p>Squashing can be performed either locally (before MR) or on GitLab (before or after MR)</p>
447 <pre data-id="code-animation">
448 <code class="bash" data-trim type="text/template">
449 # squashing locally
450
451 # squashing only a selected amount of commits...
452 # select the last 3 commits interactively,
453 # ordering them with the last at the bottom of the interactive file
454 git rebase -i HEAD~3
455 # We then mark the line at the top (chronologically the first commit) with "pick"
456 # and the rest of the lines with "squash" or "s".
457 # Finally we are also adding a proper commit message.
458
459 # Using "fixup" or "f" instead of "squash" will produce the same result,
460 # except it will not prompt for a new commit message and will use the commit
461 # message of the first commit.
462
463
464 # squashing everything...
465 git merge --squash &lt;branch-name&gt;
466 # will take all the commits from the branch, squash them,
467 # and stage all changes in the current branch
468 </code>
469 </pre>
470 </section>
471
472
473 <section>
474 <h2>Sources</h2>
475 </br>
476 <p><a href="https://en.wikipedia.org">https://en.wikipedia.org</a> - Wikipedia</p>
477 <p><a href="https://git-scm.com/book/en/v2/">https://git-scm.com/book/en/v2/</a> - Pro Git</p>
478 <p>The official man pages</p>
479 </section>
480
481
482 <section>
483 <h1>Q &amp; A</h1>
484 </section>
485
486 </div>
487 </div>
488
489 <script src="dist/reveal.js"></script>
490 <script src="plugin/zoom/zoom.js"></script>
491 <script src="plugin/notes/notes.js"></script>
492 <script src="plugin/search/search.js"></script>
493 <script src="plugin/markdown/markdown.js"></script>
494 <script src="plugin/highlight/highlight.js"></script>
495 <script>
496
497 // Also available as an ES module, see:
498 // https://revealjs.netlify.app/initialization/
499 Reveal.initialize({
500 controls: true,
501 progress: true,
502 center: true,
503 hash: true,
504
505 // Learn about plugins: https://revealjs.netlify.app/plugins/
506 plugins: [ RevealZoom, RevealNotes, RevealSearch, RevealMarkdown, RevealHighlight ]
507 });
508 Reveal.configure({ pdfSeparateFragments: false });
509
510 </script>
511
512 </body>
513</html>
generated by cgit v1.3 (git 2.53.0) at 2026-09-25 09:44:05 +0000