reorganized order again, all theory firstg
This commit is contained in:
كارل مبارك
parent
85abfb10dc
commit
a678ff5b6d
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
243
slides.rst
243
slides.rst
|
|
@ -23,12 +23,12 @@ Planning (90 min)
|
|||
=================
|
||||
|
||||
1. Context: what git is, what it does, who uses it (5 min)
|
||||
2. Core concepts: commits & three areas (10 min)
|
||||
3. Install Git (10 min)
|
||||
4. Essential commands: (10 min)
|
||||
2. Core concepts: branching & merging (5 min)
|
||||
4. Extended commands: (10 min)
|
||||
4. Forgejo: accounts + clone/push permissions (10 min)
|
||||
2. Core concepts: commits & working areas (10 min)
|
||||
3. Core concepts: branching & merging (10 min)
|
||||
4. Terminology overview (5 min)
|
||||
5. Install Git (10 min)
|
||||
6. Essential commands: (10 min)
|
||||
7. Forgejo: accounts + clone/push permissions (10 min)
|
||||
5. Exercise: branch a page, publish live, iterate (35 min)
|
||||
6. Wrap-up: good practices + next steps (5 min)
|
||||
|
||||
|
|
@ -60,13 +60,11 @@ Workshop outcome
|
|||
|
||||
Each participant will:
|
||||
|
||||
- clone a repo
|
||||
- have basic knowledge of git
|
||||
- clone a repository
|
||||
- create a branch
|
||||
- edit a simple profile website
|
||||
- commit changes with a clear message
|
||||
- push branch to Forgejo
|
||||
- see it appear in the live gallery
|
||||
|
||||
- commit changes
|
||||
- push branch to our platform
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -74,8 +72,8 @@ What is git?
|
|||
============
|
||||
|
||||
- git is a distributed version control system
|
||||
- git is a hidden sub-folder in a folder
|
||||
- git tracks changes over time to files inside a folder
|
||||
- git operates in a hidden sub-folder inside the tracked folder
|
||||
- git enables:
|
||||
|
||||
- history (time)
|
||||
|
|
@ -148,6 +146,8 @@ Core concept: Commits
|
|||
4. **Why** were the changes made?
|
||||
5. **Where** was the last checkpoint?
|
||||
|
||||
.. note::
|
||||
|
||||
Every time an author makes a set of changes that are meaningful together, she commits her changes by describing them, creating a checkpoint in the timeline to return to in the future.
|
||||
|
||||
The changes possible in a commit are:
|
||||
|
|
@ -156,7 +156,7 @@ Core concept: Commits
|
|||
- removing a file
|
||||
- renaming (moving) a file
|
||||
|
||||
Commits do not know about the timeline they are in. They only know of their preceeding commit, otherwise known as their "parent".
|
||||
Commits do not know about the timeline they are in. They only know of their preceeding commit, otherwise known as their **parent**.
|
||||
|
||||
You can always **checkout** a commit: visit the repository at that checkpoint on its timeline. Basically time-travel.
|
||||
|
||||
|
|
@ -203,7 +203,7 @@ Typical solo local workflow
|
|||
3. You stage your changes and commit them.
|
||||
4. Repeat steps **2** and **3**.
|
||||
|
||||
Use case: tracking changes on a local, private folder, such as bookkeeping.
|
||||
**Use case**: tracking changes on a local, private folder, such as bookkeeping.
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -216,7 +216,7 @@ Typical solo remote workflow
|
|||
4. You push (upload) your commit up to the remote.
|
||||
5. Repeat steps **2**, **3** and **4**
|
||||
|
||||
Use case: tracking and backing up a private folder, such as a password store.
|
||||
**Use case**: tracking and backing up a private folder, such as a password store.
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -230,13 +230,117 @@ Typical collaborative remote workflow
|
|||
5. You pull (re-download) other people's commits from the remote.
|
||||
6. Repeat steps **5**, **2**, **3** and **4**
|
||||
|
||||
Use case: tracking and collaborating on a repository with others such as a website project.
|
||||
**Use case**: tracking and collaborating on a repository with others such as a website project.
|
||||
|
||||
----
|
||||
|
||||
|
||||
Core concept: Branching
|
||||
=======================
|
||||
|
||||
.. container:: row
|
||||
|
||||
.. container::
|
||||
|
||||
In git, a **branch** is a named series of commits. In the previous example, there is only one branch, named "main" by default.
|
||||
|
||||
When you want to "take a detour" from the main course of a repository, you can create a separate branch.
|
||||
|
||||
.. note::
|
||||
|
||||
Now, parrallel timelines of the same repository exist next to each other.
|
||||
|
||||
Example **Use cases** of branching:
|
||||
- if you want to experiemnt with a new feature affecting many files
|
||||
- if you want to propose an improvement to your collaborators without editing their work "main"
|
||||
- If you want to make existing software compatible on another platform
|
||||
|
||||
|
||||
.. note::
|
||||
There is a lot of discourse around when to branch and how often. It varies from person to person and group to group.
|
||||
|
||||
From the perspective of git, since branching doesn't add any technical overload on a project, it is encouraged to branch more and branch often. From a logical perspective, every branch creates a parrallel timeline, and this might be a lot to keep track of mentally.
|
||||
|
||||
Branching allows for and encourages collaboration and is at the core of the free and open source software movement.
|
||||
|
||||
|
||||
.. image:: assets/images/branching.png
|
||||
:width: 400px
|
||||
:scale: 100 %
|
||||
|
||||
|
||||
|
||||
----
|
||||
|
||||
Core concept: Merging
|
||||
=====================
|
||||
|
||||
.. container:: row
|
||||
|
||||
.. container::
|
||||
|
||||
In git, **merging** is when you consolidate commits from a separate branch into your own.
|
||||
|
||||
.. note::
|
||||
There are various merging techniques, and most of the time, the automated algorithm will work.
|
||||
|
||||
Sometimes, you might encounter a **merge confilct**: a section of a file where both branches have conflicting changes that cannot be automatically resolved. Here, you have to manually resolve the conflicts.
|
||||
|
||||
.. note::
|
||||
which can take the form of:
|
||||
- accepting a change from one branch and rejecting the other
|
||||
- accepting and keeping both changes
|
||||
- re-editing the files to incorporate both changes
|
||||
|
||||
After merging two branches, a **merge commit** is created. This is an exceptional commit that has two parent commits instead of one.
|
||||
|
||||
.. image:: assets/images/branches.png
|
||||
:width: 300px
|
||||
:scale: 100 %
|
||||
|
||||
|
||||
----
|
||||
|
||||
Complex collaborative remote workflow
|
||||
=====================================
|
||||
|
||||
1. You clone a repository from a remote host to your local computer.
|
||||
2. You create a new branch "my-feature" for your changes.
|
||||
3. You make your changes to the repository.
|
||||
4. You stage and commit your changes.
|
||||
5. You push (upload) your commit up to the remote, publishing your branch for others to see / work on.
|
||||
6. You pull (re-download) other people's commits from the remote.
|
||||
7. Repeat steps **6**, **3**, **4** and **5**
|
||||
8. When ready, you switch back to "main" branch and merge "my-feature" branch into it.
|
||||
9. You push your new merge commit up to the "main" branch on remote.
|
||||
|
||||
|
||||
**Use case**: you are designing a website for a client and want to show 3 different versions of it with different background colours.
|
||||
|
||||
**Use case**: tracking and collaborating on a repository with others such as a website project, where two online versions of the website exist, a "safe" one that is available to the public, and an "experimental" one that is reserved for trying new features together.
|
||||
|
||||
|
||||
----
|
||||
|
||||
Terminology Overview
|
||||
====================
|
||||
|
||||
- **repository**: a directory initialised with git
|
||||
- **commit**: a checkpoint in the repository timeline(s)
|
||||
- **checkout**: to visit the repository at a specific commit in its history.
|
||||
- **delta**: a set of changes of a single commit
|
||||
- **working tree**: your files as they are right now in the repository
|
||||
- **staging area**: a place to add changes to
|
||||
- **remote**: a copy of the repository on a different host
|
||||
- **clone**: to download an identical copy of a repository
|
||||
- **push**: to upload local commits to a remote repository
|
||||
- **pull**: to re-download commits from the remote repository
|
||||
- **branch**: a named series of commits, a detour, a parallel timeline
|
||||
- **merge**: an incorporation of commits from another branch
|
||||
|
||||
----
|
||||
|
||||
|
||||
Install Git
|
||||
===========
|
||||
|
||||
|
|
@ -271,7 +375,10 @@ Commands: the essential set
|
|||
- `git checkout` (visit the timeline at a specific checkpoint)
|
||||
- `git push` (your commits to a remote server)
|
||||
- `git pull` (sync with a repo online and merge)
|
||||
|
||||
- `git branch` (take a detour)
|
||||
- `git merge` (merge branches)
|
||||
.. - `git diff` (what changed)
|
||||
.. - `git log` (history)
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -447,89 +554,6 @@ Pull updates from server:
|
|||
Pull is mainly for getting new changes on main (if needed).
|
||||
|
||||
|
||||
|
||||
----
|
||||
|
||||
Core concept: Branching
|
||||
=======================
|
||||
|
||||
.. container:: row
|
||||
|
||||
.. container::
|
||||
|
||||
In git, a **branch** is a named series of commits. In the previous example, there is only one branch, named "main" by default.
|
||||
|
||||
In a situation where you want to "take a detour" from the main course of the development of a repository, you can create a separate branch. Now, parrallel timelines of the same repository exist next to each other.
|
||||
|
||||
Example use cases of branching:
|
||||
- if you want to experiemnt with a new feature affecting many files
|
||||
- if you want to propose an improvement to your collaborators without editing their work "main"
|
||||
- If you want to make existing software compatible on another platform
|
||||
|
||||
There is a lot of discourse around when to branch and how often. It varies from person to person and group to group.
|
||||
|
||||
.. note::
|
||||
From the perspective of git, since branching doesn't add any technical overload on a project, it is encouraged to branch more and branch often. From a logical perspective, every branch creates a parrallel timeline, and this might be a lot to keep track of mentally.
|
||||
|
||||
Branching allows for and encourages collaboration and is at the core of the free and open source software movement.
|
||||
|
||||
|
||||
.. image:: assets/images/branching.png
|
||||
:width: 400px
|
||||
:scale: 100 %
|
||||
|
||||
|
||||
|
||||
----
|
||||
|
||||
Core concept: Merging
|
||||
=====================
|
||||
|
||||
.. container:: row
|
||||
|
||||
.. container::
|
||||
|
||||
In git, **merging** is when you incorporate commits from a separate branch into your own.
|
||||
|
||||
There are various merging techniques, and most of the time, the automated algorithm will work. Sometimes however, you might encounter a **merge confilct**: a section of a file where both branches have conflicting data that cannot be automatically resolved. In this case, you are prompted to manually resolve the conflicts, which can take the form of:
|
||||
- accepting a change from one branch and rejecting the other
|
||||
- accepting and keeping both changes
|
||||
- re-editing the files to incorporate both changes
|
||||
|
||||
After merging two branches, a **merge commit** is created. This is an exceptional commit that has two parent commits instead of one.
|
||||
|
||||
.. image:: assets/images/branches.png
|
||||
:width: 300px
|
||||
:scale: 100 %
|
||||
|
||||
|
||||
----
|
||||
|
||||
Complex collaborative remote workflow
|
||||
=====================================
|
||||
|
||||
1. You clone a repository from a remote host to your local computer.
|
||||
2. You create a new branch "my-feature" for your changes.
|
||||
3. You make your changes to the repository.
|
||||
4. You stage and commit your changes.
|
||||
5. You push (upload) your commit up to the remote, publishing your branch for others to see / work on.
|
||||
6. You pull (re-download) other people's commits from the remote.
|
||||
7. Repeat steps **6**, **3**, **4** and **5**
|
||||
8. When ready, you switch back to "main" branch and merge "my-feature" branch into it.
|
||||
9. You push your new merge commit up to the "main" branch on remote.
|
||||
|
||||
Use case: tracking and collaborating on a repository with others such as a website project, where multiple features and parrallel versions of the website exist.
|
||||
|
||||
|
||||
----
|
||||
|
||||
Commands: the extended set
|
||||
==========================
|
||||
- `git branch` (take a detour)
|
||||
- `git merge` (merge branches)
|
||||
.. - `git diff` (what changed)
|
||||
.. - `git log` (history)
|
||||
|
||||
----
|
||||
|
||||
Command: git branch
|
||||
|
|
@ -571,23 +595,6 @@ Command: git merge
|
|||
|
||||
|
||||
|
||||
----
|
||||
|
||||
Interlude: Terminology Overview
|
||||
===============================
|
||||
|
||||
- **repository**: a directory initialised with git
|
||||
- **commit**: a checkpoint in the repository timeline(s)
|
||||
- **checkout**: to visit the repository at a specific commit in its history.
|
||||
- **delta**: a set of changes of a single commit
|
||||
- **working tree**: your files as they are right now in the repository
|
||||
- **staging area**: a place to add changes to
|
||||
- **remote**: a copy of the repository on a different host
|
||||
- **clone**: to download an identical copy of a repository
|
||||
- **push**: to upload local commits to a remote repository
|
||||
- **pull**: to re-download commits from the remote repository
|
||||
- **branch**: a named series of commits, a detour, a parallel timeline
|
||||
- **merge**: an incorporation of commits from another branch
|
||||
|
||||
----
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue