Back again with some fixed

book/workflows/branches.md

@@ -1,4 +1,4 @@
-# Create your own version
+# Create your own version (branching, cloning, pulling)
 
 Branches are a very useful feature of Git. Branches allow you to work on multiple versions of your codebase simultaneously; you create a copy of your codebase, on which you can work independently of the main codebase. The main branch is the default branch. The content on this branch will be the most up to date version of the book. Therefore, new branches, which are made to add or fix some content in the book, are usually cloned from the main branch. This has many advantages compared to making the edits immediately in the main branch.  Some advantages of working with branches are:
 

book/workflows/collaboration.md

@@ -43,7 +43,7 @@ The steps involved are as follows:
 - Add changes to Git-timeline locally (committing)
 - Add changes to GitHub/GitLab (pushing)
 ````
-````{tab-item} Brand new version (branch)
+````{tab-item} Existing version (branch)
 - Eventually solve conflicts with combining versions (merge conflicts, emerges after pulling)
 - Add or make changes to file(s)
 - Select files ready to be added to Git-timeline (staging)
@@ -61,7 +61,7 @@ The steps involved are as follows:
 - Add changes to Git-timeline locally (committing)
 - Add changes to GitHub/GitLab (pushing)
 ````
-````{tab-item} Brand new version (branch)
+````{tab-item} Existing version (branch)
 - Eventually solve conflicts with combining versions (merge conflicts, emerges after pulling)
 - Add or make changes to file(s)
 - Check changes in book locally

book/workflows/edit_book.md

@@ -1,4 +1,4 @@
-# Edit
+# Edit (merge conflicts, staging, committing, pushing)
 
 Suppose we are writing a new chapter, or are updating an existing chapter for our Jupyter Book. We've created a new branch on which we are going to make the changes.
 

book/workflows/merge_request.md

@@ -1,4 +1,4 @@
-# Reviewing and combine versions
+# Reviewing and combine versions (merge / pull request, merging)
 
 Merging a branch into the main branch is also good moment to let a team-member review the content. By assigning a colleague to review your branch you can check the quality of your new content. 
 
@@ -6,7 +6,7 @@ Merging a branch into the main branch is also good moment to let a team-member r
 There is a slight difference in terminology between GitLab and GitHub. GitLab uses the term *Merge* Request while GitHub uses the term *Pull* Request. Both actions refer to the merging of a branch into the main branch.
 ```
 
-We're finished with our chapter, and now it's time to include all of our commits in the `main` branch. However, it's good practise to first merge `main` into our branch, so that we can see if there are any merge conflicts. Assuming that those merge conflicts are solved before, we'll now continue this example with the following merge of our branch into `main`.
+We're finished with our chapter, and now it's time to include all of our commits in the `main` branch. However, it's good practice to first merge `main` into our branch, so that we can see if there are any merge conflicts. Assuming that those merge conflicts are solved before, we'll now continue this example with the following merge of our branch into `main`.
 
 `````{tab-set}
 ````{tab-item} In GitLab

book/workflows/milestones_issues.md

@@ -1,4 +1,4 @@
-# Assign task to yourself
+# Assign task to yourself (milestones, issues)
 
 In a repository, team members can define Milestones and Issues. Milestones are used to track the overall progress of the project to make sure that deadlines are met. A milestone can group many issues, which are individual tasks that need to be finished in order to reach the milestone.
 
@@ -16,7 +16,7 @@ Every team member can create issues when they think of a task that would improve
 
 The issues in GitLab can be found on this page:
 
-![issues](figures/issues.png)
+![issues](figures/issues_new.png)
 
 You can create an issue by clicking on the blue `New Issue` button in the top right corner.