Merge branch '4-move-tagging-to-episode-10' into 'master'

Resolve "Move tagging to episode 10"

Closes #4

See merge request hifis/hifis-workshops/introduction-to-git-and-gitlab/workshop-material!4

episodes/08-conflicts.md

@@ -34,7 +34,7 @@ In addition, [conflicts.pptx](extras/conflicts.pptx) shows an animation of all p
 ## Create a new Branch and start your Work
 
 - Show the existing branches
-  - `git branch --all`
+  - `git branch`
   - Explain the labels `master` and `HEAD`
 - Show graph of the repository
   - Draw state of the repository
@@ -65,9 +65,9 @@ o - o <- HEAD, master, mummy-info
   - Verify with `git graph`
 
 ```
-      o <- HEAD, mummy-info
+      o - o <- HEAD, mummy-info
      /
-o - o   <- master
+o - o       <- master
 ```
 
 ## Prepare the Conflict
@@ -81,9 +81,9 @@ o - o   <- master
   - Verify with `git graph`
 
 ```
-      o   <- mummy-info
+      o - o  <- mummy-info
      /
-o - o - o <- HEAD, master
+o - o - o    <- HEAD, master
 ```
 
 ## Merge and Resolve the Conflict
@@ -101,9 +101,9 @@ o - o - o <- HEAD, master
   - Highlight that no version/commit is lost in a merge
 
 ```
-        o     <- mummy-info
-      /   \
-o - o - o - o <- HEAD, master
+       o -  o     <- mummy-info
+      /      \
+o - o - o  -  o   <- HEAD, master
 ```
 
 - Clean up the local branch
@@ -111,13 +111,14 @@ o - o - o - o <- HEAD, master
   - Verfiy with `git branch` and `git graph`
 
 ```
-        o
-      /   \
-o - o - o - o <- HEAD, master
+       o -  o
+      /      \
+o - o - o  -  o   <- HEAD, master
 ```
 
 ## Key Points
 
+- Branching is an important concept in Git
 - Git can merge diverging files line-based
   - unless the same line is changed in different ways
 - Resolve conflicts by editing the `<<< ... === ... >>>` sections

episodes/09-remotes-in-gitlab.md

@@ -13,33 +13,30 @@ Please see the original episodes for further details about the introduced topics
 ## Repositories
 
 - There are different options and use cases for multiple repositories as shown in: [Git-SCM.com/about/distributed](https://git-scm.com/about/distributed)
+- Explain that we are using a `shared repository` which is used for synchronizing the work of all involved persons.
+
+## Publish the local Repository in GitLab
+
 - Create an **empty** GitLab project named `planets` and visibility `private` via the [GitLab Web interface](https://gitlab.com/help/gitlab-basics/create-project.md):
   - Explain available options & usefulness of description for [`/explore` filter](https://gitlab.com/explore/projects)
   - Ask, what happens when the create button is clicked ([`git init --bare`](https://swcarpentry.github.io/git-novice/fig/git-freshly-made-github-repo.svg)).
     - `Initialize ... README` would cause "Initial commit" (this option should be unchecked!)
-
-## Remotes
-
 - Explain the concept of **Remotes**
   - Preview [`clone`, `fetch` vs. `pull`, `push` commands][remote-overview]
-- Copy URL from newly created repository:
-  - Explicitly mention: Copy URL via clipboard button => "invisible" character issues
-- **Challenge:** Which of the `Command line instructions` applies to us? **Answer:** "Push ... existing ..." 
-  - Check existing: `git remote -v` => skip `rename`
-  - Explain the naming convention for `origin`
-  - `git remote add origin URL`
-- Show that a new remote was added:
-  - `git remote -v`
-  - Explain `fetch` and `push`
-
-### Push and Pull
-
+  - Copy URL from newly created repository and explicitly mention to copy the URL via the clipboard button ("invisible" character issues)
+  - **Challenge:** Which of the `Command line instructions` applies to us? **Answer:** "Push ... existing ..." 
+  - Explain the naming convention for `origin` ("origin" from which everyone starts)
+  - Set the remote: `git remote add origin URL`
+  - Show that a new remote was added: `git remote -v` (explain `fetch` and `push`)
 - Push the recent changes to the new repository:
   - `git push`
-  - Try only `git push`, note `--set-upstream` hint & apply it
-- **Exercise:** [Push vs. Commit](https://swcarpentry.github.io/git-novice/07-github/index.html#push-vs-commit)
-- Show push result in GitLab:
+  - Explain the error message and fix it via the `--set-upstream` hint
+- Show the result in GitLab:
   - Explain usefulness of good commit messages for `History` and `Blame` views
+- **Exercise:** [Push vs. Commit](https://swcarpentry.github.io/git-novice/07-github/index.html#push-vs-commit)
+
+## Change the remote Repository and synchronize locally
+
 - Create the file `venus.txt` via the GitLab Web interface:
   - Add line: `Wolfman will appreciate the absence of moons`
   - Set `Commit message` to `"Start notes on Venus as a base"`
@@ -47,25 +44,17 @@ Please see the original episodes for further details about the introduced topics
 - Change the file `mars.txt` via the GitLab Web interface:
   - Add line: `We have to bring our own oxygen`
   - Set `Commit message` to `"Add notes about Mars' atmosphere"`
-- Compare GitLab-`Graph` with local `git log --oneline`
-  - `git fetch` and `git status` => "behind"
-  - `git log --oneline --all`
-- Pull and show log and `git status` => "up to date with 'origin/master'"
+- Fetch the changes
+  - `git fetch`
+  - `git log --oneline --all` and compare with the `Graph` in GitLab
+  - `git status` => "behind"
+- Integrate the changes into the local `master` branch
+  - `git pull` 
+  - `git status` => "up to date with 'origin/master'"
   - Highlight difference to **working copies** in SVN
   - Explain that all changes were included **without** merge commit ("fast-forward")
   - Show [Atlassian's "Fast Forward Merge" figure](https://www.atlassian.com/git/tutorials/using-branches/git-merge)
 
-### Mark the Results Using a Tag
-
-- [Human-usable pointer to a point in the version history](https://www.endoflineblog.com/img/oneflow/hotfix-branch-merge-final.png)
-  (similar to branch names & `HEAD`)
-- Create a tag:
-  - `git tag v1.0 -m "First publishable draft"`
-- Push the tag to the remote repository:
-  - `git push origin v1.0`
-  - Explain that `--tags` will push all tags at once
-  - Explain that `v1.0`, `HEAD`, a commit ID and a branch name can refer to the same commit
-
 ## Key Points
 
 - Local copy is backup of remote => Different local backup needed!

episodes/10-collaboration-with-others.md

@@ -25,7 +25,7 @@ In the following, we work from the collaborator's point of view and want to cont
 
 - Clone the remote Git repository:
    - `git clone <REMOTE URL>`
-   - Show where to retrieve URL from in Gitlab
+   - Show where to retrieve the URL in Gitlab
 - Show current state of the cloned local Git repository:
    - `git graph`
    - Highlight current branches
@@ -53,7 +53,7 @@ In the following, we work from the collaborator's point of view and want to cont
 
 ## Review the Contribution (Owner View)
 
-Now, we switch into the role of the project owner (you) and review the contribution.
+Now, we switch into the role of the project owner and review the contribution.
 
 - Switch to the newly created merge request and review it (see also: [GitLab's documentation about managing merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/reviewing_and_managing_merge_requests.html)):
   - Explain about basic aspects to check:
@@ -67,7 +67,7 @@ Now, we switch into the role of the project owner (you) and review the contribut
 
 ## Pull Changes (Collaborator View)
 
-Finally, the collaborator pulls the resulting `master` branch to make sure that the local Git repository is up-to-date.
+Then, the collaborator pulls the resulting `master` branch to make sure that the local Git repository is up-to-date.
 For that purpose, we switch to our local Git repository.
 
 - Switch to branch `master`:
@@ -79,8 +79,23 @@ For that purpose, we switch to our local Git repository.
    - `git graph`
    - Highlight that both `master` branches now point to the merge commit
 
+## Mark the Results using a Tag (Owner View)
+
+Finally, the owner marks the current state via a tag.
+
+- [Tags are human-usable pointer to mark important points in the version history](https://www.endoflineblog.com/img/oneflow/hotfix-branch-merge-final.png)
+  (similar to branch names & `HEAD`)
+- Create a tag:
+  - `git tag v0.1 -m "Mark initial version"`
+- Push the tag to the remote repository:
+  - `git push origin v0.1`
+  - Explain that `--tags` will push all tags at once
+  - Explain that `v0.1`, `HEAD`, a commit ID and a branch name can refer to the same commit
+- Show the tag in GitLab
+
 ## Key Points
 
 - Branches allow you to track code changes for different tasks in parallel.
 - Merge requests should be used for reviews and visual tracking of changes before merge.
 - `git fetch` can be used to update information of tracked remotes.
+- Tags help you to mark important versions explicitly.