Merge pull request #257 from UCL/saransh/headings

Uniform headings + about libraries should be before installing

ch00git/01Intro.ipynb.py

@@ -12,10 +12,10 @@
 # ---
 
 # %% [markdown]
-# ## Introduction
+# # Introduction
 
 # %% [markdown]
-# ### What's version control?
+# ## What's version control?
 #
 # Version control is a tool for __managing changes__ to a set of files.
 #
@@ -28,7 +28,7 @@
 # - ...
 
 # %% [markdown]
-# ### Why use version control?
+# ## Why use version control?
 #
 # - Better kind of __backup__.
 # - Review __history__ ("When did I introduce this bug?").
@@ -43,14 +43,14 @@
 # - "How can I submit a change to someone else's code?"
 # - "How can I merge my work with Sue's?"
 #
-# ### Git != GitHub
+# ## Git != GitHub
 #
 # - __Git__: version control system tool to manage source code history.
 #
 # - __GitHub__: hosting service for Git repositories.
 
 # %% [markdown]
-# ### How do we use version control?
+# ## How do we use version control?
 #
 # Do some programming, then commit our work:
 #
@@ -65,7 +65,7 @@
 # Mistake is undone.
 
 # %% [markdown]
-# ### What is version control? (Team version)
+# ## What is version control? (Team version)
 #
 # Graham             | Eric
 # ------------------ |------   
@@ -82,7 +82,7 @@
 # `my_vcs commit`    | ...
 
 # %% [markdown]
-# ### Scope
+# ## Scope
 #
 # This course will use the `git` version control system, but much of what you learn will be valid with other version control 
 # tools you may encounter, including subversion (`svn`) and mercurial (`hg`).
@@ -91,28 +91,28 @@
 # ## Practising with Git
 
 # %% [markdown]
-# ### Example Exercise
+# ## Example Exercise
 #
 # In this course, we will use, as an example, the development of a few text files containing a description of a topic of your choice. 
 #
 # This could be your research, a hobby, or something else. In the end, we will show you how to display the content of these files as a very simple website. 
 
 # %% [markdown]
-# ### Programming and documents
+# ## Programming and documents
 #
 # The purpose of this exercise is to learn how to use Git to manage program code you write, not simple text website content, but we'll just use these text files instead of code for now, so as not to confuse matters with trying to learn version control while thinking about programming too. 
 #
 # In later parts of the course, you will use the version control tools you learn today with actual Python code.
 
 # %% [markdown]
-# ### Markdown
+# ## Markdown
 #
 # The text files we create will use a simple "wiki" markup style called [markdown](http://daringfireball.net/projects/markdown/basics) to show formatting. This is the convention used in this file, too. 
 #
 # You can view the content of this file in the way Markdown renders it by looking on the [web](https://github.com/UCL/ucl_software_carpentry/blob/master/git/git_instructions.md), and compare the [raw text](https://raw.github.com/UCL/ucl_software_carpentry/master/git/git_instructions.md).
 
 # %% [markdown]
-# ### Displaying Text in this Tutorial
+# ## Displaying Text in this Tutorial
 #
 # This tutorial is based on use of the Git command line. So you'll be typing commands in the shell.
 
@@ -145,7 +145,7 @@
 # On either Windows, Mac or Linux, we recommend [VS Code](https://code.visualstudio.com/).
 
 # %% [markdown]
-# ### Setting up somewhere to work
+# ## Setting up somewhere to work
 
 # %% attributes={"classes": [" Bash"], "id": ""} jupyter={"outputs_hidden": false} language="bash"
 # rm -rf learning_git/git_example # Just in case it's left over from a previous class; you won't need this
@@ -173,7 +173,7 @@
 # %% [markdown]
 # ## Solo work
 #
-# ### Configuring Git with your name and email
+# ## Configuring Git with your name and email
 #
 # First, we should configure Git to know our name and email address:
 
@@ -191,7 +191,7 @@
 # Historically, the default branch was named `master`. Nowadays, the community and most of the hosting sites have changed the default ([read about this change in GitHub](https://github.com/github/renaming/) and [Gitlab](https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/).
 
 # %% [markdown]
-# ### Initialising the repository
+# ## Initialising the repository
 #
 # Now, we will tell Git to track the content of this folder as a git "repository".
 

ch00git/02Solo.ipynb.py

@@ -12,7 +12,7 @@
 # ---
 
 # %% [markdown]
-# ## Solo work with Git
+# # Solo work with Git
 
 # %% [markdown]
 # **NOTE:** using bash/git commands is not fully supported on jupyterlite yet (due to single
@@ -31,7 +31,7 @@
 working_dir
 
 # %% [markdown]
-# ### A first example file
+# ## A first example file
 #
 # So let's create an example file, and see how to start to manage a history of changes to it.
 
@@ -50,7 +50,7 @@
 # cat index.md
 
 # %% [markdown]
-# ### Telling Git about the File
+# ## Telling Git about the File
 #
 # So, let's tell Git that `index.md` is a file which is important, and we would like to keep track of its history:
 
@@ -60,7 +60,7 @@
 # %% [markdown]
 # Don't forget: Any files in repositories which you want to "track" need to be added with `git add` after you create them.
 #
-# ### Our first commit
+# ## Our first commit
 #
 # Now, we need to tell Git to record the first version of this file in the history of changes:
 
@@ -73,7 +73,7 @@
 # There's a lot of output there you can ignore for now.
 
 # %% [markdown]
-# ### Configuring Git with your editor
+# ## Configuring Git with your editor
 #
 # If you don't type in the log message directly with -m "Some message", then an editor will pop up, to allow you
 # to edit your message on the fly.
@@ -102,7 +102,7 @@
 # I'm going to be using `nano` as my editor, but you can use whatever editor you prefer. Find how to setup your favourite editor in [the setup chapter of Software Carpentry's Git lesson](https://swcarpentry.github.io/git-novice/02-setup.html).
 
 # %% [markdown]
-# ### Git log
+# ## Git log
 #
 # Git now has one change in its history:
 
@@ -113,7 +113,7 @@
 # You can see the commit message, author, and date...
 
 # %% [markdown]
-# ### Hash Codes
+# ## Hash Codes
 #
 # The commit "hash code", e.g.
 #
@@ -124,7 +124,7 @@
 # (This is a really long code, but whenever you need to use it, you can just use the first few characters, however many characters is long enough to make it unique, `c438` for example. )
 
 # %% [markdown]
-# ### Nothing to see here
+# ## Nothing to see here
 #
 # Note that git will now tell us that our "working directory" is up-to-date with the repository: there are no changes to the files that aren't recorded in the repository history:
 
@@ -150,7 +150,7 @@
 # cat index.md
 
 # %% [markdown]
-# ### Unstaged changes
+# ## Unstaged changes
 
 # %% attributes={"classes": [" Bash"], "id": ""} jupyter={"outputs_hidden": false} language="bash"
 # git status
@@ -174,7 +174,7 @@
 # Deleted lines are prefixed with a minus, added lines prefixed with a plus.
 
 # %% [markdown]
-# ### Staging a file to be included in the next commit
+# ## Staging a file to be included in the next commit
 #
 # To include the file in the next commit, we have a few choices. This is one of the things to be careful of with git: there are lots of ways to do similar things, and it can be hard to keep track of them all.
 
@@ -187,14 +187,14 @@
 # Note that `git add` is the command we use to introduce git to a new file, but also the command we use to "stage" a file to be included in the next commit. 
 
 # %% [markdown]
-# ### The staging area
+# ## The staging area
 #
 # The "staging area" or "index" is the git jargon for the place which contains the list of changes which will be included in the next commit.
 #
 # You can include specific changes to specific files with `git add`, commit them, add some more files, and commit them. (You can even add specific changes within a file to be included in the index.)
 
 # %% [markdown]
-# ### Message Sequence Charts
+# ## Message Sequence Charts
 
 # %% [markdown]
 # In order to illustrate the behaviour of Git, it will be useful to be able to generate figures in Python
@@ -237,7 +237,7 @@ def wsd(code):
 wsd("Sender->Recipient: Hello\n Recipient->Sender: Message received OK")
 
 # %% [markdown]
-# ### The Levels of Git
+# ## The Levels of Git
 
 # %% [markdown]
 # Let's make ourselves a sequence chart to show the different aspects of Git we've seen so far:
@@ -251,7 +251,7 @@ def wsd(code):
 wsd(message)
 
 # %% [markdown]
-# ### Review of status
+# ## Review of status
 
 # %% attributes={"classes": [" Bash"], "id": ""} jupyter={"outputs_hidden": false} language="bash"
 # git status
@@ -266,7 +266,7 @@ def wsd(code):
 # Great, we now have a file which contains a mistake.
 
 # %% [markdown]
-# ### Carry on regardless
+# ## Carry on regardless
 #
 # In a while, we'll use Git to roll back to the last correct version: this is one of the main reasons we wanted to use version control, after all! But for now, let's do just as we would if we were writing code, not notice our mistake and keep working...
 
@@ -289,7 +289,7 @@ def wsd(code):
 # cat index.md
 
 # %% [markdown]
-# ### Review of changes
+# ## Review of changes
 
 # %% attributes={"classes": [" Bash"], "id": ""} jupyter={"outputs_hidden": false} language="bash"
 # git log | head
@@ -301,7 +301,7 @@ def wsd(code):
 # git log --oneline
 
 # %% [markdown]
-# ### Git Solo Workflow
+# ## Git Solo Workflow
 
 # %% [markdown]
 # We can make a diagram that summarises the above story:

ch00git/03Mistakes.ipynb.py

@@ -12,7 +12,7 @@
 # ---
 
 # %% [markdown]
-# ## Fixing mistakes
+# # Fixing mistakes
 
 # %% [markdown]
 # **NOTE:** using bash/git commands is not fully supported on jupyterlite yet (due to single
@@ -31,7 +31,7 @@
 working_dir
 
 # %% [markdown]
-# ### Referring to changes with HEAD and ^
+# ## Referring to changes with HEAD and ^
 #
 # The commit we want to revert to is the one before the latest.
 #
@@ -40,7 +40,7 @@
 # We could use the hash code (e.g. 73fbeaf) to reference this, but you can also refer to the commit before the `HEAD` as `HEAD^`, the one before that as `HEAD^^`, the one before that as `HEAD~3`.
 
 # %% [markdown]
-# ### Reverting
+# ## Reverting
 #  
 # Ok, so now we'd like to undo the nasty commit with the lie about Mount Fictional.
 
@@ -51,7 +51,7 @@
 # An editor may pop up, with some default text which you can accept and save. 
 
 # %% [markdown]
-# ### Conflicted reverts
+# ## Conflicted reverts
 #
 # You may, depending on the changes you've tried to make, get an error message here. 
 #
@@ -60,28 +60,28 @@
 # If that happens, you need to manually edit the file to fix the problem. Skip ahead to the section on resolving conflicts, or ask a demonstrator to help.
 
 # %% [markdown]
-# ### Review of changes
+# ## Review of changes
 #
 # The file should now contain the change to the title, but not the extra line with the lie. Note the log:
 
 # %% jupyter={"outputs_hidden": false} language="bash"
 # git log --date=short
 
 # %% [markdown]
-# ### Antipatch
+# ## Antipatch
 #
 # Notice how the mistake has stayed in the history.
 #
 # There is a new commit which undoes the change: this is colloquially called an "antipatch". 
 # This is nice: you have a record of the full story, including the mistake and its correction.
 
 # %% [markdown]
-# ### Rewriting history
+# ## Rewriting history
 #
 # It is possible, in git, to remove the most recent change altogether, "rewriting history". Let's make another bad change, and see how to do this.
 
 # %% [markdown]
-# ### A new lie
+# ## A new lie
 
 # %% jupyter={"outputs_hidden": false}
 # %%writefile index.md
@@ -106,7 +106,7 @@
 # git log --date=short
 
 # %% [markdown]
-# ### Using reset to rewrite history
+# ## Using reset to rewrite history
 
 # %% attributes={"classes": [" Bash"], "id": ""} jupyter={"outputs_hidden": false} language="bash"
 # git reset HEAD^
@@ -115,12 +115,12 @@
 # git log --date=short
 
 # %% [markdown]
-# ### Covering your tracks
+# ## Covering your tracks
 #
 # The silly spelling *is no longer in the log*. This approach to fixing mistakes, "rewriting history" with `reset`, instead of adding an antipatch with `revert`, is dangerous, and we don't recommend it. But you may want to do it for small silly mistakes, such as to correct a commit message.
 
 # %% [markdown]
-# ### Resetting the working area
+# ## Resetting the working area
 #
 # When `git reset` removes commits, it leaves your working directory unchanged -- so you can keep the work in the bad change if you want.