+author: TeachBooks Team from Delft university of Technology, built with TeachBooks and Jupyter Book, CC BY 4.0
logo: images/Logo_without_background.png
diff --git a/book/_toc.yml b/book/_toc.yml
index 7589782..15f9117 100644
--- a/book/_toc.yml
+++ b/book/_toc.yml
@@ -6,7 +6,6 @@ parts:
chapters:
- file: installation-and-setup/user_types
- file: installation-and-setup/git
- - file: installation-and-setup/choose_platforms.md
- file: installation-and-setup/overview
sections:
- file: installation-and-setup/vscode-setup
@@ -22,7 +21,7 @@ parts:
- file: workflows/edit_book
- file: workflows/check_changes_online
- file: workflows/merge_request
- - file: workflows/publish
+ - file: installation-and-setup/organize-team
- caption: Features
chapters:
- file: basic-features/overview
diff --git a/book/examples/example_gumbel.ipynb b/book/examples/example_gumbel.ipynb
index 9095c4c..e23cc7a 100644
--- a/book/examples/example_gumbel.ipynb
+++ b/book/examples/example_gumbel.ipynb
@@ -34,20 +34,6 @@
"To complete this assignment, you can use `numpy`, `matplotlib` and from the `math` library, `log` and `e` (these are imported for you when you inialize the notebook)."
]
},
- {
- "cell_type": "code",
- "execution_count": null,
- "metadata": {
- "tags": [
- "thebe-remove-input-init"
- ]
- },
- "outputs": [],
- "source": [
- "import micropip\n",
- "await micropip.install(\"ipywidgets\")"
- ]
- },
{
"cell_type": "code",
"execution_count": 2,
diff --git a/book/examples/grading.py b/book/examples/grading.py
new file mode 100644
index 0000000..c282bf3
--- /dev/null
+++ b/book/examples/grading.py
@@ -0,0 +1,16 @@
+from IPython.display import display
+import ipywidgets as widgets
+
+def check(f):
+ def wrapper(*args, **kwargs):
+ output = widgets.Output()
+ button = widgets.Button(description="Check Answer(s)")
+ @output.capture(clear_output=True,wait=True)
+ def _inner_check(button):
+ try:
+ f(*args, **kwargs)
+ except:
+ print("Something went wrong, have you filled all the functions and run the cells?")
+ button.on_click(_inner_check)
+ display(button, output)
+ return wrapper
diff --git a/book/external/deploy-book-workflow b/book/external/deploy-book-workflow
index 32e1eb8..d5eab25 160000
--- a/book/external/deploy-book-workflow
+++ b/book/external/deploy-book-workflow
@@ -1 +1 @@
-Subproject commit 32e1eb8725fe4c63612a13f7467491cc9765d95e
+Subproject commit d5eab25a29e2cc558ec449577dab669c02758a11
diff --git a/book/external/template b/book/external/template
index 1f74f5f..7165661 160000
--- a/book/external/template
+++ b/book/external/template
@@ -1 +1 @@
-Subproject commit 1f74f5f2cf71a282e29b9a96a61bb8a140b9c6ab
+Subproject commit 71656612afa24342f345d9e113553b8ff3cdf4b1
diff --git a/book/features/creating_basic_HTML_elements.md b/book/features/creating_basic_HTML_elements.md
index 3d44023..806395d 100644
--- a/book/features/creating_basic_HTML_elements.md
+++ b/book/features/creating_basic_HTML_elements.md
@@ -57,7 +57,7 @@ The first few lines of our JavaScript code are simple. To scale our element with
Next, we may want to define some functions for our element. The first function `linspace` is simply creates `resolution` points between a `start` and `end` value, similar to `numpy.linspace` in Python. The second and third functions evaluate the pdf and cdf of a standard Gaussian distribution for a given `x` value.
-```html
+```
function linspace(start, end, resolution) {
var spacing = [];
// Go through a for-loop
@@ -189,7 +189,7 @@ Now, let us add actual content. We start by creating 201 equally-spaced points o
Next, we concatenate our `x` and `pdf` vectors into a list of dictionaries, which we then convert into pixel coordinates with a `valueline_pdf` function we create. Finally, we add it to the subplot as a `path` via the `svg.append("path")` function. In addition, we want to represent the fact that the cdf (which we will later plot on the right) represents the integral of all pdf values to the left of the current x-value. To this end, we want to create a filled shape that highlights this area. We can do so by creating another path that follows the pdf from the left border to the currently selected value (initially: `x=0`), then moves back to the subplot origin along the x-axis. The path-information `data_fill` is created the same way as before, but now we add it as a `svg.append("path")` that has the `fill` attribute, which - as the name implies - fills the region inside it with a solid color.
-```html
+```
// Evaluate the normal pdf
var x = linspace(-3, 3, 201);
var pdf = standard_Gaussian_pdf(x);
@@ -252,7 +252,7 @@ Next, we concatenate our `x` and `pdf` vectors into a list of dictionaries, whic
The next block essentially repeats the same procedure for the right subplot, but replaces the pdf evaluation with a cdf evaluation. We also add a dashed horizontal line that marks the integral value on the y-axis. Go through the code and see if you recognize parallels to the code above.
-```html
+```
// Define a subplot for the standard normal
const y_limits_cdf = [0, 1];
const window_x_cdf = [width * 0.585, width * 0.985];
@@ -367,7 +367,7 @@ One of the nice things about these interactive JavaScript elements is that you c
Finally, we close all open environments, and are done with this simple interactive element!
-```html
+```
// Shift the marker around on mouseover; restrict it to the contour
var movex, movey, xpos
diff --git a/book/features/live_code.ipynb b/book/features/live_code.ipynb
index 0c356e7..1111605 100644
--- a/book/features/live_code.ipynb
+++ b/book/features/live_code.ipynb
@@ -85,7 +85,7 @@
"If you push to main, you can test the interactivity on the book-draft website as well.\n",
"\n",
"## Custom cell tags\n",
- "With the extended functionality of live code, additional cell tags have been developed to be added to cells in any .ipynb file, next to the [existing tags] of the jupyter book (https://jupyterbook.org/en/stable/content/metadata.html):\n",
+ "With the extended functionality of live code, additional cell tags have been developed to be added to python cells (not markdown cells) in any .ipynb file, next to the [existing tags] of the jupyter book (https://jupyterbook.org/en/stable/content/metadata.html):\n",
"- `disable-execution-cell` disables the ability to execute the cell when thebe is activated. This might be useful if you notebook file includes interactivity for only a part of the coding cells\n",
"- `disable-execution-page` disables the ability to execute the entire page. This might be useful if you use python code for creating a page, but the code is not part of the actual content of the book.\n",
"- `auto-execute-page` automatically starts the thebe live coding functionality whenever the page is opened. This is particularly useful if you're using widgets on a page.\n",
diff --git a/book/installation-and-setup/choose_platforms.md b/book/installation-and-setup/choose_platforms.md
index 0fe5589..2a4232a 100644
--- a/book/installation-and-setup/choose_platforms.md
+++ b/book/installation-and-setup/choose_platforms.md
@@ -9,7 +9,7 @@ Now that you can start, there's a first choice to be made, where to host your bo
- Github allows you to host your book on the GitHub server using GitHub pages (to be recognized by the `
There are multiple tools of providing feedback in the built book: a) Using the [hypothesis](https://jupyterbook.org/en/stable/interactive/comments/hypothesis.html)-extension which allows public/private highlighting and annotating parts of the book. An example can be seen on the [MUDE website](https://mude.citg.tudelft.nl/book/intro.html). b) Using the [Utterances](https://jupyterbook.org/en/stable/interactive/comments/utterances.html)-extension which allows commenting on pages for books which are hosted on GitHub. Those comments are converted to issues on GitHub for the editors to handle.
+1. **Students providing feedback on the published website**. There are multiple tools of providing feedback in the built book: a) using the issue button in the top-right corner to directly create issues visible to the editor team. b) Using the [hypothesis](https://jupyterbook.org/en/stable/interactive/comments/hypothesis.html)-extension which allows public/private highlighting and annotating parts of the book. An example can be seen on the [MUDE website](https://mude.citg.tudelft.nl/book/intro.html). c) Using the [Utterances](https://jupyterbook.org/en/stable/interactive/comments/utterances.html)-extension which allows commenting on pages for books which are hosted on GitHub visible for everyone. Those comments are converted to issues on GitHub for the editors to handle.
2. **Colleague providing feedback on the draft website**. In a similar manner as students, colleages and team members can leave content related comments on the website through extensions. In this way, multiple teachers can give input in the draft of the textbook and course material without requiring and exact understanding of Jupyter Books or GitLab/GitHub. The responsible teacher (or student assistants) can then make the adaptations to the book as recommended by their colleagues. diff --git a/book/intro.md b/book/intro.md index 1471cd6..290839f 100644 --- a/book/intro.md +++ b/book/intro.md @@ -3,4 +3,6 @@ This is an introduction to Git, VS Code and Jupyter Books for teachers and teaching assistants involved in TeachBooks, our platform easing the process of making a
. This book is still work in progress, so feel free to contribute https://gitlab.tudelft.nl/interactivetextbooks-citg/jupyter-book-manual! For more information about teachbooks, visit [https://teachbooks.tudelft.nl/](https://teachbooks.tudelft.nl/).
## Contact
-If you encounter any issues, please contact Tom van Woudenberg, Robert Lanzafame or one of our TAs Julie Kirsch at TeachBooks@tudelft.nl.
\ No newline at end of file
+If you encounter any issues and you've a TU Delft account, report it by clicking --> {fa}`lightbulb` on the top right corner of this page. Or contribute directly by creating a merge request in the [repository](https://gitlab.tudelft.nl/interactivetextbooks-citg/jupyter-book-manual).
+
+If you've questions, contact Tom van Woudenberg, Robert Lanzafame or our TAs Julie Kirsch at TeachBooks@tudelft.nl, also for non-TU Delft account holders. TU Delft account holder can also contact us in the [MS Teams Open Interactive Textbooks Community](https://teams.microsoft.com/l/team/19%3Ah9-uRcP_yYauh-VuoPFozJVUvHVOB4a0mz1ZWvh4q4Q1%40thread.tacv2/conversations?groupId=3e88c1f3-4a4f-483a-a366-7e617de9ba99&tenantId=096e524d-6929-4030-8cd3-8ab42de0887b)
\ No newline at end of file
diff --git a/book/workflows/branches.md b/book/workflows/branches.md
index 464f74e..6535e1b 100644
--- a/book/workflows/branches.md
+++ b/book/workflows/branches.md
@@ -80,19 +80,15 @@ Tip: It makes sense to give the branch a name related to the content you will be
As user type 4 and 5, you make changes to the book locally on your computer rather than online on GitLab/GitHub. This allows you to create more complex and interactive sections to your book. Before you can start, there are a few preparatory steps you need to take.
-**Cloning**
+In order to create your own version, you will first have to open the repository. Then, you will need to clone the repository to your computer. This procedure is called cloning.
-In order to create your own version, you will first have to open the repositery. Then, you will need to clone the repositery to your computer. This procedure is called cloning.
-
-**Branching**
-
-If your repositery is already cloned on your computer, you are almost ready to start editing the book. However, remember that you are most likely not the only person making changes to the book. To keep an overview of the changes made by you and your colleages, it is important that changes are first made in a 'copy' of the book and are then merged into the final version. This is done through branching! You can create your version of the book by creating a new version (branch) or you can continue the work in an existing version (checkout branch).
+If your repository is already cloned on your computer, you are almost ready to start editing the book. However, remember that you are most likely not the only person making changes to the book. To keep an overview of the changes made by you and your colleages, it is important that changes are first made in a 'copy' of the book and are then merged into the final version. This is done through branching! You can create your version of the book by creating a new version (branch) or you can continue the work in an existing version (checkout branch).
`````````{tab-set}
-````````{tab-item} Cloning
+````````{tab-item} ... when opening repository for first timeโฆ
-**1. Open the repository locally using ...**
+**(a) ... by finding the repository url from ...**
```````{tab-set}
@@ -146,7 +142,7 @@ You have now directly cloned the repository, so you can skip the next step!
``````
```````
-**2. Clone the local repositery with ...**
+**(b) ... and opening (cloning) the local repository with ...**
```````{tab-set}
``````{tab-item} ... VS Code
@@ -166,10 +162,10 @@ The VS Code welcome screen.
``````{tab-item} ... GitHub Desktop
-1. You have previously copied the link of the repositery you would like to clone from GitLab or GitHub. In GitHub Desktop, navigate to the top bar, click on `File` and then on `Clone repositery`.
+1. You have previously copied the link of the repository you would like to clone from GitLab or GitHub. In GitHub Desktop, navigate to the top bar, click on `File` and then on `Clone repository`.
+ 
+**You have now cloned the repository to your computer and you can start branching.
Have a look at the other section!** ```````` -````````{tab-item} Branching +````````{tab-item} ... when working in previously opened repositoryโฆ -**I want to...
-(a) update my repository (pulling) and
-(b) create my own version (branching) or select an existing version (checkout branch) using ...** +**(a) by creating my own version (branching) or select an existing version (checkout branch) ...** -```````{tab-set} -``````{tab-item} ... Git in VS Code - -**1. Update your repositery** - -Since you are working in a repositery with multiple colleagues, it is good practice to make sure your local repositery is up to date before you start branching. This is especially important when you want to work in an existing branch. In that case you want to make sure that the existing branch shows in your local repositery. Therefore, you first need to pull all the changes from the remote repositery to your local repositery. Simply click the Icon with the two arrows. - -```{figure} ../figures/Pull_VS.png -:name: Pull_VS - -Location of the branch menu. -``` -Once your local repositery is up to date you can start to work either in a new branch (new version) or in an existing branch (exisiting version). - -**2. Create your own version by creating a new branch** - -Although it is possible to create new branches in VS Code directly, creating new branches on the remote repositery (on GitLab or GitHub) is better for collaborating because the new branch becomes immediately visible to everyone working in the repositery as opposed to becoming visible after being pushed to the remote repositery. - -Create a new branch in... +Although it is possible to create new branches in VS Code directly, creating new branches on the remote repository (on GitLab or GitHub) is better for collaborating because the new branch becomes immediately visible to everyone working in the repository as opposed to becoming visible after being pushed to the remote repository. `````{tab-set} -````{tab-item} ... GitLab +````{tab-item} ... in GitLab 1. Navigate to the repository of your project. Under the project description, you should see a menu button with a "+" in it (see {numref}`new-branch-button`). Click this button, then click on "New branch". @@ -240,10 +216,7 @@ We're making a new branch called `chapter-2` from the `main` branch. The circled menu is the branch selection menu. ``` - -You have now created a new branch on the remote, make sure to fetch & pull again to see it on the local repositery! ```` - ````{tab-item} ... GitHub 1. Open the repository in which you want to work in. In the top bar you will see your current branch `main` and next to that there is a tab called `Branches`. @@ -271,11 +244,15 @@ Tip: It makes sense to give the branch a name related to the content you will be
-5. jupYou have now created a new branch on the remote, make sure to fetch & pull again to see it on the local repositery!
````
`````
-**3. Work in an existing branch**
+**(b) and updating my local repository (checking out and pulling) ...**
+
+```````{tab-set}
+``````{tab-item} ... with Git in VS Code
+
+1. Open own version (checking out)
If you want to work in an existing branch you need to *check out* our new branch in VS Code. *Checking out* means that we're changing our working branch (i.e., the one to which we will be committing our changes) from one to the other.
@@ -294,91 +271,25 @@ Location of the branch menu.
The branch selection menu, where our new branch has shown up. From this menu you can also select (checkout in git terms) another existing branch.
```
+
+2. Update your local repository
+
+Since you are working in a repository with multiple colleagues, it is good practice to make sure your local repository is up to date. This is especially important when you want to work in an existing branch. In that case you want to make sure that the existing branch shows in your local repository. Therefore, you first need to pull all the changes from the remote repository to your local repository. Simply click the Icon with the two arrows.
+
+```{figure} ../figures/Pull_VS.PNG
+:name: Pull_VS
+
+Location of the branch menu.
+```
+
``````
-``````{tab-item} ... GitHub Desktop
+``````{tab-item} ... with GitHub Desktop
-**1. Update your repositery**
-
-Since you are working in a repositery with multiple colleagues, it is good practice to make sure your local repositery is up to date before you start branching. This is especially important when you want to work in an existing branch. In that case you want to make sure that the existing branch shows in your local repositery. Therefore, you first need to pull all the changes from the remote repositery to your local repositery.
-
-This synchronizes the remote repositery with your local repositery on your computer. Click on `Fetch` in the top bar. Then on the same place, click on 'Pull'.
-
-
-
-
--Tip: It makes sense to give the branch a name related to the content you will be creating or altering. - -
-
-
+
--(a) opening the repository locally (cloning) and
-(b) creating your own version (branching) or selecting existing version (checkout branch):** +(a) creating your own version (branching) +(b) opening the repository locally (cloning) and selecting correct version (checkout branch):**
+ - branching - cloning - - branching / checkout branch + - checkout branch ```` ````{tab-item} Work in previously opened repository... **... by
-(a) updating your repository (pulling) and
-(b) creating your own version (branching) or select existing version (checkout branch):** - +(a) creating your own version (branching)
+(b) updating your repository (pulling) and select correct version (checkout branch):** + + - branching - pulling - branching / checkout branch ```` @@ -126,7 +128,6 @@ The steps involved are as follows: ```` `````` ``````` - 4. **Check candles nline** + 4. **Check changes online** 5. **Repeat steps 3 and 4 until you're satisfied** - 6. **Reviewing (merge request), (eventually repeat steps 3 and 4) and combine (merging) your version with main draft version of book** - 7. **Publish changes to student version of the book (merge request)** + 6. **Reviewing (merge request), (eventually repeat steps 3 and 4) and combine (merging) your version with main draft version of book** \ No newline at end of file diff --git a/book/workflows/edit_book.md b/book/workflows/edit_book.md index f79e0b4..7b7af0e 100644 --- a/book/workflows/edit_book.md +++ b/book/workflows/edit_book.md @@ -11,9 +11,9 @@ Suppose we are writing a new chapter, or are updating an existing chapter for ou `````{tab-set} ````{tab-item} ... GitLab -In GitLab, you can directly make changes in the files on the remote repositery. You can make changes to the files already in the repositery using the text editor but you can also upload new files! +In GitLab, you can directly make changes in the files on the remote repository. You can make changes to the files already in the repository using the text editor but you can also upload new files! -1. Navigate to the repositery you want to work in. +1. Navigate to the repository you want to work in and make sure you're in the correct branch. 2. Create a new file by clicking on the plus button in the top bar. You can either create an entirely new file by clicking `New File` or if you already have created a file you can upload it by clicking `Upload File`. @@ -21,25 +21,25 @@ In GitLab, you can directly make changes in the files on the remote repositery.
-3. In the new window, you can start typing your content. Give your file a name and make sure to use the markdown extension: `Chapter1.md`. Once you are done, commit the new file to the repositery by clicking the blue button `Commit changes`.
+3. In the new window, you can start typing your content. Give your file a name and make sure to use the markdown extension: `Chapter1.md`. Once you are done, commit the new file to the repository by clicking the blue button `Commit changes`.
@@ -49,9 +49,9 @@ You can edit it and commit the changes in the same manner as with markdown (.md)
````
````{tab-item} ... GitHub
-In GitHub, you can directly make changes in the files on the remote repositery. You can make changes to the files already in the repositery using the text editor but you can also upload new files!
+In GitHub, you can directly make changes in the files on the remote repository. You can make changes to the files already in the repository using the text editor but you can also upload new files!
-1. Navigate to the repositery you want to work in.
+1. Navigate to the repository you want to work in and make sure you're in the correct branch.
2. Create a new file by clicking on the button called `Add file` in the top bar. You can either create an entirely new file by clicking `Create new File` or if you already have created a file you can upload it by clicking `Upload files`.
@@ -59,25 +59,25 @@ In GitHub, you can directly make changes in the files on the remote repositery.
@@ -92,10 +92,10 @@ You can edit it and commit the changes in the same manner as with markdown (.md)
```````{tab-set}
``````{tab-item} ... for a brand new version (branch)...
-**... by (1) making changes on a single or multiple file(s) - (2) selecting changes to be added to the Git-timeline (staging)
- (3) adding changes to the Git-timeline (committing) and
- (4) adding changes to GitLab/GitHub (pushing) with ...** +**... by (a) making changes on a single or multiple file(s)
+ (b) selecting changes to be added to the Git-timeline (staging)
+ (c) adding changes to the Git-timeline (committing) and
+ (d) adding changes to GitLab/GitHub (pushing) with ...** `````{tab-set} ````{tab-item} ... Git in VS Code @@ -123,7 +123,7 @@ The new file has been staged, and we've written a Commit Message. ``` Now, we are ready to add the changes to the repository. This is done by *committing* the staged changes. To do this, simply press the big, blue "Commit" button in the Source Control menu. -In the bottom left corner, next to the branch name, click the "Synchronize Changes" button (the one that looks like this: ๐, highlighted in the image below) to push the changes to GitLab. +4. In the bottom left corner, next to the branch name, click the "Synchronize Changes" button (the one that looks like this: ๐, highlighted in the image below) to push the changes to GitLab. ```{figure} ../images/git-push.png @@ -140,9 +140,9 @@ After committing, click the ๐ button to push our changes to the remote reposi
@@ -159,17 +159,17 @@ Alternatively, you can also click on `Push origin` in the top bar.
``````{tab-item} ... for an existing version (branch)...
-**... by (1) regularly obtaining updates from colleagues from GitLab/GitHub (pulling), - (2) solving potential incompatible changes (merging conflicts),
- (3) making changes on a single / multiple file(s),
- (4) selecting changes to be added to the Git-timeline (staging),
- (5) adding those to the Git-timeline (committing) and
- (6) adding changes to GitLab/GitHub (pushing) with ...** +**... by (a) regularly obtaining updates from colleagues from GitLab/GitHub (pulling),
+ (b) solving potential incompatible changes (merging conflicts),
+ (c) making changes on a single / multiple file(s),
+ (d) selecting changes to be added to the Git-timeline (staging),
+ (e) adding those to the Git-timeline (committing) and
+ (f) adding changes to GitLab/GitHub (pushing) with ...** `````{tab-set} ````{tab-item} ... Git in VS Code -1. If you collaborate with colleagues on your branch, you can get the updates from your colleagues as well by pulling from GitLab/GitHub. This synchronizes the remote repositery with your local repositery on your machine. On the left side-bar click on the icon that looks like a branch. +1. If you collaborate with colleagues on your branch, you can get the updates from your colleagues as well by pulling from GitLab/GitHub. This synchronizes the remote repository with your local repository on your machine. On the left side-bar click on the icon that looks like a branch.
@@ -177,7 +177,7 @@ Alternatively, you can also click on `Push origin` in the top bar.
By clicking on the ๐ button, you will pull your colleages' changes.
-2. When multiple people work on one chapter, it is possible that conflicts will arise if you and your colleagues have made incompatible changes in the same branch. In that case, when pulling from the remote repositery, Git in VS Code will recognize conflicts and help you to solve potential incompatible changes (merging conflicts). Open the files that are marked as conflicitng.
+2. When multiple people work on one chapter, it is possible that conflicts will arise if you and your colleagues have made incompatible changes in the same branch. In that case, when pulling from the remote repository, Git in VS Code will recognize conflicts and help you to solve potential incompatible changes (merging conflicts). Open the files that are marked as conflicitng.
@@ -214,7 +214,7 @@ The new file has been staged, and we've written a Commit Message.
```
Now, we are ready to add the changes to the repository. This is done by *committing* the staged changes. To do this, simply press the big, blue "Commit" button in the Source Control menu.
-In the bottom left corner, next to the branch name, click the "Synchronize Changes" button (the one that looks like this: ๐, highlighted in the image below) to push the changes to GitLab.
+6. In the bottom left corner, next to the branch name, click the "Synchronize Changes" button (the one that looks like this: ๐, highlighted in the image below) to push the changes to GitLab.
```{figure} ../images/git-push.png
@@ -222,19 +222,19 @@ After committing, click the ๐ button to push our changes to the remote reposi
````
````{tab-item} ... GitHub Desktop
-1. If you collaborate with colleagues on your branch, you can get the updates from your colleagues as well by pulling from GitLab/GitHub. This synchronizes the remote repositery with your local repositery on your machine. Click on `Fetch` in the top bar. Then on the same place, click on 'Pull'.
+1. If you collaborate with colleagues on your branch, you can get the updates from your colleagues as well by pulling from GitLab/GitHub. This synchronizes the remote repository with your local repository on your machine. Click on `Fetch` in the top bar. Then on the same place, click on 'Pull'.
@@ -256,9 +256,9 @@ Choose one of the options to resolve the merge conflict. You now have updated yo
@@ -281,11 +281,11 @@ Alternatively, you can also click on `Push origin` in the top bar.
```````{tab-set}
``````{tab-item} ... for brand new version (branch)
-**... by (1) making changes on a single or multiple file(s) - (2) checking changes locally,
- (3) selecting changes to be added to the Git-timeline (staging)
- (4) adding changes to the Git-timeline (committing) and
- (5) adding changes to GitLab/GitHub (pushing) with ...** +**... by (a) making changes on a single or multiple file(s)
+ (b) checking changes locally,
+ (c) selecting changes to be added to the Git-timeline (staging)
+ (d) adding changes to the Git-timeline (committing) and
+ (e) adding changes to GitLab/GitHub (pushing) with ...** `````{tab-set} ````{tab-item} ... Git in VS Code @@ -301,7 +301,7 @@ You will firstly need to actiavte the right environment. Type the following comm (or the environment in which you have installed the TeachBooks package) -Then we can build the book locally. Make sure you are in the right repositery in VS code and type the folloing command: +Then we can build the book locally. Make sure you are in the right repository in VS code and type the folloing command: `jupyter-book build book` @@ -370,7 +370,7 @@ You will firstly need to actiavte the right environment. Type the following comm (or the environment in which you have installed the TeachBooks package) -Then we can build the book locally. Make sure you are in the right repositery in VS code and type the folloing command: +Then we can build the book locally. Make sure you are in the right repository in VS code and type the folloing command: `jupyter-book build book` @@ -397,9 +397,9 @@ The staging GitHub Desktop assumes you want to stage all files. These files will
@@ -423,18 +423,18 @@ You can read more about it [here](/book/installation-and-setup/jupyter-book-setu
``````{tab-item} ... for an existing version (branch)
-**... by (1) regularly obtaining updates from colleagues from GitLab/GitHub (pulling), - (2) solving potential incompatible changes (merging conflicts),
- (3) making changes on a single / multiple file(s),
- (4) checking changes locally,
- (5) selecting changes to be added to the Git-timeline (staging),
- (6) adding those to the Git-timeline (committing) and
- (7) adding changes to GitLab/GitHub (pushing) with ...** +**... by (a) regularly obtaining updates from colleagues from GitLab/GitHub (pulling),
+ (b) solving potential incompatible changes (merging conflicts),
+ (c) making changes on a single / multiple file(s),
+ (d) checking changes locally,
+ (e) selecting changes to be added to the Git-timeline (staging),
+ (f) adding those to the Git-timeline (committing) and
+ (g) adding changes to GitLab/GitHub (pushing) with ...** `````{tab-set} ````{tab-item} ... Git in VS Code -1. If you collaborate with colleagues on your branch, you can get the updates from your colleagues as well by pulling from GitLab/GitHub. This synchronizes the remote repositery with your local repositery on your machine. On the left side-bar click on the icon that looks like a branch. +1. If you collaborate with colleagues on your branch, you can get the updates from your colleagues as well by pulling from GitLab/GitHub. This synchronizes the remote repository with your local repository on your machine. On the left side-bar click on the icon that looks like a branch.
@@ -442,7 +442,7 @@ You can read more about it [here](/book/installation-and-setup/jupyter-book-setu
By clicking on the ๐ button, you will pull your colleages' changes.
-2. When multiple people work on one chapter, it is possible that conflicts will arise if you and your colleagues have made incompatible changes in the same branch. In that case, when pulling from the remote repositery, Git in VS Code will recognize conflicts and help you to solve potential incompatible changes (merging conflicts). Open the files that are marked as conflicitng.
+2. When multiple people work on one chapter, it is possible that conflicts will arise if you and your colleagues have made incompatible changes in the same branch. In that case, when pulling from the remote repository, Git in VS Code will recognize conflicts and help you to solve potential incompatible changes (merging conflicts). Open the files that are marked as conflicitng.
@@ -467,7 +467,7 @@ You will firstly need to actiavte the right environment. Type the following comm
(or the environment in which you have installed the TeachBooks package)
-Then we can build the book locally. Make sure you are in the right repositery in VS code and type the folloing command:
+Then we can build the book locally. Make sure you are in the right repository in VS code and type the folloing command:
`jupyter-book build book`
@@ -514,19 +514,19 @@ After committing, click the ๐ button to push our changes to the remote reposi
````
````{tab-item} ... GitHub Desktop
-1. If you collaborate with colleagues on your branch, you can get the updates from your colleagues as well by pulling from GitLab/GitHub. This synchronizes the remote repositery with your local repositery on your machine. Click on `Fetch` in the top bar. Then on the same place, click on 'Pull'.
+1. If you collaborate with colleagues on your branch, you can get the updates from your colleagues as well by pulling from GitLab/GitHub. This synchronizes the remote repository with your local repository on your machine. Click on `Fetch` in the top bar. Then on the same place, click on 'Pull'.
diff --git a/book/workflows/merge_request.md b/book/workflows/merge_request.md
index 10a4208..acf79ea 100644
--- a/book/workflows/merge_request.md
+++ b/book/workflows/merge_request.md
@@ -51,7 +51,7 @@ In case you have cloned the repositery you can also resolve the conflicts locall
6. On the page of our merge request ({numref}`gitlab-finished-merge-request`), we're greeted with some more information. On top, you can read the description we just provided when creating the merge request. We can also see an "Approve" button, which you may or may not see, depending on your repository rights. Next, we can see a green checkmark, with a "Merge" button. This is good news: our changes do not conflict with existing files on the `main` branch, and we can merge our changes directly by clicking the button (if applicable: only after somebody else approved the request).
-```{figure} ../images/gitlab-finished-merge-request.png
+```{figure} ../../images/gitlab-finished-merge-request.png
:name: gitlab-finished-merge-request
The finished merge request.
@@ -108,7 +108,7 @@ In case you have cloned the repositery you can also resolve the conflicts locall
