Before you can
git pull, you need to have committed any changes you have made. If you find you want to pull, but you're not ready to commit, you have to temporarily "put aside" your uncommitted changes.
For this, you can use the
git stash command, like in the following example:
import os top_dir = os.getcwd() git_dir = os.path.join(top_dir, 'learning_git') working_dir = os.path.join(git_dir, 'git_example') os.chdir(working_dir)
%%writefile Wales.md Mountains In Wales ================== * Pen y Fan * Tryfan * Snowdon * Glyder Fawr * Fan y Big * Cadair Idris
%%bash git stash git pull
No local changes to save Already up to date.
By stashing your work first, your repository becomes clean, allowing you to pull. To restore your changes, use
git stash apply.
%%bash --no-raise-error git stash apply
No stash entries found.
The "Stash" is a way of temporarily saving your working area, and can help out in a pinch.
Tags are easy to read labels for revisions, and can be used anywhere we would name a commit.
Produce real results only with tagged revisions
%%bash git tag -a v1.0 -m "Release 1.0" git push --tags
To github.com:UCL/github-example.git ! [rejected] v1.0 -> v1.0 (already exists) error: failed to push some refs to 'github.com:UCL/github-example.git' hint: Updates were rejected because the tag already exists in the remote.
--------------------------------------------------------------------------- CalledProcessError Traceback (most recent call last) Cell In, line 1 ----> 1 get_ipython().run_cell_magic('bash', '', 'git tag -a v1.0 -m "Release 1.0"\ngit push --tags\n') File /opt/hostedtoolcache/Python/3.8.15/x64/lib/python3.8/site-packages/IPython/core/interactiveshell.py:2417, in InteractiveShell.run_cell_magic(self, magic_name, line, cell) 2415 with self.builtin_trap: 2416 args = (magic_arg_s, cell) -> 2417 result = fn(*args, **kwargs) 2418 return result File /opt/hostedtoolcache/Python/3.8.15/x64/lib/python3.8/site-packages/IPython/core/magics/script.py:153, in ScriptMagics._make_script_magic.<locals>.named_script_magic(line, cell) 151 else: 152 line = script --> 153 return self.shebang(line, cell) File /opt/hostedtoolcache/Python/3.8.15/x64/lib/python3.8/site-packages/IPython/core/magics/script.py:305, in ScriptMagics.shebang(self, line, cell) 300 if args.raise_error and p.returncode != 0: 301 # If we get here and p.returncode is still None, we must have 302 # killed it but not yet seen its return code. We don't wait for it, 303 # in case it's stuck in uninterruptible sleep. -9 = SIGKILL 304 rc = p.returncode or -9 --> 305 raise CalledProcessError(rc, cell) CalledProcessError: Command 'b'git tag -a v1.0 -m "Release 1.0"\ngit push --tags\n'' returned non-zero exit status 1.
%%writefile Pennines.md Mountains In the Pennines ======================== * Cross Fell
%%bash git add Pennines.md git commit -am "Add Pennines"
[main 84c3078] Add Pennines 1 file changed, 5 insertions(+) create mode 100644 Pennines.md
You can also use tag names in the place of commmit hashes, such as to list the history between particular commits:
%%bash git log v1.0.. --graph --oneline
* 84c3078 Add Pennines
If .. is used without a following commit name, HEAD is assumed.
We often end up with files that are generated by our program. It is bad practice to keep these in Git; just keep the sources.
.x files for compiled languages,
.pyc files in Python.
In our example, we might want to make our .md files into a PDF with pandoc:
%%writefile Makefile MDS=$(wildcard *.md) PDFS=$(MDS:.md=.pdf) default: $(PDFS) %.pdf: %.md pandoc $< -o $@
make: Entering directory '/home/runner/work/rsd-engineeringcourse/rsd-engineeringcourse/ch02git/learning_git/git_example' pandoc Pennines.md -o Pennines.pdf pandoc Scotland.md -o Scotland.pdf pandoc Wales.md -o Wales.pdf pandoc index.md -o index.pdf pandoc lakeland.md -o lakeland.pdf make: Leaving directory '/home/runner/work/rsd-engineeringcourse/rsd-engineeringcourse/ch02git/learning_git/git_example'
We now have a bunch of output .pdf files corresponding to each Markdown file.
But we don't want those to show up in git:
%%bash git status
On branch main Your branch is ahead of 'origin/main' by 2 commits. (use "git push" to publish your local commits) Untracked files: (use "git add <file>..." to include in what will be committed) Makefile Pennines.pdf Scotland.md Scotland.pdf Wales.pdf __pycache__/ index.pdf lakeland.pdf wsd.py nothing added to commit but untracked files present (use "git add" to track)
Use .gitignore files to tell Git not to pay attention to files with certain paths:
%%writefile .gitignore *.pdf
%%bash git status
On branch main Your branch is ahead of 'origin/main' by 2 commits. (use "git push" to publish your local commits) Untracked files: (use "git add <file>..." to include in what will be committed) .gitignore Makefile Scotland.md __pycache__/ wsd.py nothing added to commit but untracked files present (use "git add" to track)
%%bash git add Makefile git add .gitignore git commit -am "Add a makefile and ignore generated files" git push
[main 52aaa8f] Add a makefile and ignore generated files 2 files changed, 9 insertions(+) create mode 100644 .gitignore create mode 100644 Makefile
To github.com:UCL/github-example.git e61697c..52aaa8f main -> main
Sometimes you end up creating various files that you do not want to include in version control. An easy way of deleting them (if that is what you want) is the
git clean command, which will remove the files that git is not tracking.
%%bash git clean -fX
Removing Pennines.pdf Removing Scotland.pdf Removing Wales.pdf Removing index.pdf Removing lakeland.pdf
Makefile Pennines.md Scotland.md Wales.md __pycache__ index.md lakeland.md wsd.py
- With -f: don't prompt
- with -d: remove directories
- with -x: Also remote .gitignored files
- with -X: Only remove .gitignore files
+import matplotlib +import numpy as np from matplotlib import pylab from matplotlib.backends.backend_pdf import PdfPages +def increment_or_add(key,hash,weight=1): + if key not in hash: + hash[key]=0 + hash[key]+=weight + data_path=os.path.join(os.path.dirname( os.path.abspath(__file__)), -regenerate=False +regenerate=True
git add and
git reset can be used to stage/unstage a whole file,
but you can use interactive mode to stage by hunk, choosing
yes or no for each hunk.
git add -p myfile.py
+import matplotlib +import numpy as np #Stage this hunk [y,n,a,d,/,j,J,g,e,?]?
GitHub will publish repositories containing markdown as web pages, automatically.
You'll need to add this content:
A pair of lines with three dashes, to the top of each markdown file. This is how GitHub knows which markdown files to make into web pages. Here's why for the curious.
%%writefile index.md --- title: Github Pages Example --- Mountains and Lakes in the UK =================== Engerland is not very mountainous. But has some tall hills, and maybe a mountain or two depending on your definition.
%%bash git commit -am "Add github pages YAML frontmatter"
[main 125468e] Add github pages YAML frontmatter 1 file changed, 7 insertions(+), 4 deletions(-)
The gh-pages branch¶
GitHub creates github pages when you use a special named branch.
This is best used to create documentation for a program you write, but you can use it for anything.
%%bash git switch -c gh-pages git push -uf origin gh-pages
Switched to a new branch 'gh-pages' To github.com:UCL/github-example.git + bda303d...125468e gh-pages -> gh-pages (forced update)
branch 'gh-pages' set up to track 'origin/gh-pages'.
The first time you do this, GitHub takes a few minutes to generate your pages.
The website will appear at
http://username.github.io/repositoryname, for example:
UCL layout for GitHub pages¶
You can use GitHub pages to make HTML layouts, here's an example of how to do it, and how it looks. We won't go into the detail of this now, but after the class, you might want to try this.