changed orde rto do brnaching/merging in secodn part
This commit is contained in:
parent
a573ea27f4
commit
85abfb10dc
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
394
slides.rst
394
slides.rst
|
|
@ -23,9 +23,11 @@ Planning (90 min)
|
|||
=================
|
||||
|
||||
1. Context: what git is, what it does, who uses it (5 min)
|
||||
2. Core concepts: commits & three areas (15 min)
|
||||
2. Core concepts: commits & three areas (10 min)
|
||||
3. Install Git (10 min)
|
||||
2. Core concepts: branching & merging (15 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)
|
||||
5. Exercise: branch a page, publish live, iterate (35 min)
|
||||
6. Wrap-up: good practices + next steps (5 min)
|
||||
|
|
@ -49,12 +51,30 @@ If you have been working on a file on your computer and the directory starts to
|
|||
|
||||
Then git can be helpful!
|
||||
|
||||
|
||||
|
||||
----
|
||||
|
||||
Workshop outcome
|
||||
================
|
||||
|
||||
Each participant will:
|
||||
|
||||
- clone a repo
|
||||
- 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
|
||||
|
||||
|
||||
----
|
||||
|
||||
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 enables:
|
||||
|
||||
|
|
@ -79,10 +99,35 @@ What is git not?
|
|||
================
|
||||
|
||||
- git ≠ Github!
|
||||
- Not a backup system (though it can help)
|
||||
- Not a file sync tool (though it can be used like that)
|
||||
- Not a CMS (though it can be used like that)
|
||||
- Not magic: it stores snapshots + metadata, you still choose what to record
|
||||
- git ≠ backup system (though it can help)
|
||||
- git ≠ file sync tool (though it can be used like that)
|
||||
- git ≠ CMS (though it can be used like that)
|
||||
- git ≠ magic: it stores snapshots + metadata, you still choose what to record
|
||||
|
||||
|
||||
----
|
||||
|
||||
Ecosystem
|
||||
=========
|
||||
|
||||
- **git**: the version control system itself
|
||||
- **.git**: a hidden subfolder where git operates
|
||||
- **git hosts**: platforms where git repositories are hosted
|
||||
|
||||
- GitHub, Bitbucket, GitLab (operated by Big Tech Giants)
|
||||
- Alternatives
|
||||
|
||||
- Codeberg (non-profit, community led)
|
||||
- Oxacab (riseup.net for activists, journalists)
|
||||
- Forgejo / Gitea (self-hosted)
|
||||
|
||||
- **git clients**: tools used to work with git on your computer
|
||||
|
||||
- ``git`` command line tool (free & open source)
|
||||
- ``tig`` command line tool (free & open source)
|
||||
- sourcetree, Github Desktop, VS Code (operated by Big Tech)
|
||||
- many code editors (e.g. sublime, atom) have git extensions
|
||||
- many, many more tools and extensions
|
||||
|
||||
|
||||
----
|
||||
|
|
@ -146,102 +191,6 @@ Core concept: Three Areas
|
|||
This is why Git feels "archival":
|
||||
- you intentionally select what becomes part of the record.
|
||||
|
||||
----
|
||||
|
||||
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 %
|
||||
|
||||
----
|
||||
|
||||
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
|
||||
- **branch**: a named series of commits, a detour, a prrallel timeline
|
||||
- **merge**: an incorporation of commits from another branch
|
||||
- **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
|
||||
|
||||
----
|
||||
|
||||
Ecosystem
|
||||
=========
|
||||
|
||||
- **git**: the version control system itself
|
||||
- **.git**: a hidden subfolder where git operates
|
||||
- **git hosts**: platforms where git repositories are hosted
|
||||
|
||||
- GitHub, Bitbucket, GitLab (operated by Big Tech Giants)
|
||||
- Alternatives
|
||||
|
||||
- Codeberg (non-profit, community led)
|
||||
- Oxacab (riseup.net for activists, journalists)
|
||||
- Forgejo / Gitea (self-hosted)
|
||||
|
||||
- **git clients**: tools used to work with git on your computer
|
||||
|
||||
- ``git`` command line tool (free & open source)
|
||||
- ``tig`` command line tool (free & open source)
|
||||
- sourcetree, Github Desktop, VS Code (operated by Big Tech)
|
||||
- many code editors (e.g. sublime, atom) have git extensions
|
||||
- many, many more tools and extensions
|
||||
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -283,37 +232,8 @@ Typical collaborative remote workflow
|
|||
|
||||
Use case: tracking and collaborating on a repository with others such as a website project.
|
||||
|
||||
----
|
||||
|
||||
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.
|
||||
|
||||
----
|
||||
|
||||
|
||||
Workshop outcome
|
||||
================
|
||||
|
||||
Each participant will:
|
||||
|
||||
- clone a repo
|
||||
- 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
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -336,25 +256,22 @@ Minimum requirement: you can run `git` in a terminal.
|
|||
|
||||
|
||||
|
||||
|
||||
----
|
||||
|
||||
Commands: the essential set
|
||||
===========================
|
||||
|
||||
- `git status` (always)
|
||||
- `git init` (initalise a repo)
|
||||
- `git clone` (an existing repo)
|
||||
- `git status` (what's happening?)
|
||||
- `git add` (add changes to the commit)
|
||||
- `git rm` (remove a tracked file)
|
||||
- `git commit` (store changes in the repo)
|
||||
- `git add` (add files to the commit)
|
||||
- `git fetch` (sync with a repo online)
|
||||
- `git pull` (sync with a repo online and merge)
|
||||
- `git log` (see the timeline)
|
||||
- `git checkout` (visit the timeline at a specific checkpoint)
|
||||
- `git branch` (take a detour)
|
||||
- `git merge` (merge branches)
|
||||
- `git diff` (what changed)
|
||||
- `git log` (history)
|
||||
- `git push` (your commits to a remote server)
|
||||
- `git pull` (sync with a repo online and merge)
|
||||
|
||||
- plus: log, diff
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -425,10 +342,26 @@ Stage everything (use carefully):
|
|||
|
||||
Staging is curatorial: select what belongs together.
|
||||
|
||||
|
||||
----
|
||||
|
||||
Optional: git rm
|
||||
================
|
||||
|
||||
Remove a tracked file and stage the removal:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git rm old.html
|
||||
git commit -m "Remove old page"
|
||||
|
||||
For this workshop you probably will not need it.
|
||||
|
||||
|
||||
----
|
||||
|
||||
Command: git commit
|
||||
========================================
|
||||
===================
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
|
@ -471,8 +404,136 @@ Gives a quick "finding aid" of earlier commits. Press 'q' to exit.
|
|||
|
||||
----
|
||||
|
||||
Command: git branch and git checkout
|
||||
====================================
|
||||
Command: git checkout (timetravel)
|
||||
==================================
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git checkout your_commit_id
|
||||
|
||||
See your working tree as it would have been at a specific commit on the timeline.
|
||||
|
||||
|
||||
----
|
||||
|
||||
Command: git push
|
||||
=================
|
||||
|
||||
Push your branch to the server:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git push -u origin people/yourname
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git push
|
||||
|
||||
|
||||
----
|
||||
|
||||
Command: git pull
|
||||
=================
|
||||
|
||||
Pull updates from server:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git pull
|
||||
|
||||
.. note::
|
||||
|
||||
During the exercise you mostly push your branch.
|
||||
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
|
||||
===================
|
||||
|
||||
List branches:
|
||||
|
||||
|
|
@ -504,39 +565,29 @@ Shortcut (create + switch):
|
|||
|
||||
----
|
||||
|
||||
Command: git push / git pull
|
||||
============================
|
||||
Command: git merge
|
||||
===================
|
||||
|
||||
Push your branch to the server:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git push -u origin people/yourname
|
||||
|
||||
Pull updates from server:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git pull
|
||||
|
||||
.. note::
|
||||
|
||||
During the exercise you mostly push your branch.
|
||||
Pull is mainly for getting new changes on main (if needed).
|
||||
|
||||
----
|
||||
|
||||
Optional: git rm
|
||||
================
|
||||
Interlude: Terminology Overview
|
||||
===============================
|
||||
|
||||
Remove a tracked file and stage the removal:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git rm old.html
|
||||
git commit -m "Remove old page"
|
||||
|
||||
For this workshop you probably will not need it.
|
||||
- **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
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -572,8 +623,11 @@ Resources:
|
|||
- live gallery URL: https://braids.hackersanddesigners.nl
|
||||
- these slides: https://braids.hackersanddesigners.nl/slides
|
||||
|
||||
|
||||
|
||||
----
|
||||
|
||||
|
||||
Exercise overview
|
||||
=================
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue