diff --git a/episodes/08-conflicts.md b/episodes/08-conflicts.md index bdb65cb3d914e7e2a0383c8951473c969adaabc8..d61f2ac1ae904dfae654dfb6ee6b15b8d88756ed 100644 --- a/episodes/08-conflicts.md +++ b/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 diff --git a/episodes/09-remotes-in-gitlab.md b/episodes/09-remotes-in-gitlab.md index cfe32a854b07456966f565089bc1f0db812199e4..825b7911616cbbf0a267d5092c520356dea68600 100644 --- a/episodes/09-remotes-in-gitlab.md +++ b/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! diff --git a/episodes/10-collaboration-with-others.md b/episodes/10-collaboration-with-others.md index f555e467b3dc2b73b9ed343307cf4cd395a466b0..f79f443e5690ccbcf142cce7763b337de3ddb7d7 100644 --- a/episodes/10-collaboration-with-others.md +++ b/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.