GETTING STARTED WITH

GIT AND GITHUB

How I learned to stop worrying and love version control
David Chin, Drexel URCF
• Does you source code directory/folder look like this?
• my_program-4Feb2022.py
• my_program-14Mar2022.py
• my_program.py
• my_program-algorithm1.py
• my_program-algorithm2.py
• Sidebar
• If you want to use dates, use YYYYMMDD or YYYY-
MM-DD which can be sorted numerically, e.g.
2022-02-04, 2022-03-14
MOTIVATION
• Fine for a very small number of files
• Does not scale
• Not sustainable, i.e. when you come back to your
code some months/years later
• What is an effective an efficient way of keeping
track of changes?
• By the end of this talk, you should be able to:
• Explain why version control is useful
• Create a new GitHub repository
• Use a simple (branchless) Git workflow
• Edit
• Add (Stage)
• Commit WHAT YOU
• Tag
• Push
WILL LEARN
• Use a simple branching Git workflow
• Create branch
• Switch branch
• Merge changes
• Recover a previous state of code
• a.k.a. revision control, source control, or source
code management (SCM)
• Class of systems responsible for managing
changes to computer programs, documents,
large web sites, or other collections of
information

VERSION • Two major classes

• Centralized
CONTROL • One central repository holds the “truth”
• Only one person modifies one part of
the code at a time
• Distributed
• All repositories are equal
• Repositories can be synced to each
other
• Allows for experimenting with new sections of
code while enabling reversion to older known
working state
WHAT IT CAN • Allows for collaboration with careful rules about
“clobbering” (overwriting) each other’s work
DO FOR YOU • Allows meaningful version numbers
• Not just for computer code: I used version
control on my dissertation
• Originally written by Linus Torvalds (author of
Linux) in 2005
• Used to manage Linux kernel source code:
GIT ~25 million of lines of code, thousands of
developers, all making modifications at the
same time
• Can be complex but only small subset of
commands needed for useful work
• While git is distributed, it is helpful to have a
conceptually central repository
• For a project with multiple developers in different
locations, their PCs may not be able to

GITHUB communicated directly with each other to sync

changes. GitHub serves as an intermediary.
• Students get some “pro” features for free
• Provides own GitHub CLI tool called “gh”
• We will not use it here
All these work with Git:
• GitLab
• BitBucket
• GitBucket
• AWS CodeCommit

ALTERNATIVES • SourceForge
• Google Cloud Source Repositories
TO GITHUB • Phabricator
• Gitea (self-hosted)
• Apache Allura
• Launchpad (by Canonical, distributors of Ubuntu
Linux)
• Ref: https://www.geeksforgeeks.org/top-10-
github-alternatives-that-you-can-consider
SIGN UP FOR A
GITHUB ACCOUNT
https://education.github.com/disco
unt_requests/student_application
SSH KEYS
https://docs.github.com/en/authent
ication/connecting-to-github-with-
ssh
• Allows passwordless connection with GitHub
• Generate key:
• ssh-keygen -t ed25519 -C
[email protected]
• DO NOT USE AN EMPTY PASSPHRASE
• Start the SSH agent:
• eval "$(ssh-agent -s)"

SSH KEYS • Add your key to the agent:

• ssh-add ~/.ssh/id_ed25519
• Add the public key to your GitHub account:
• cat ~/.ssh/id_ed25519.pub
• Test connection to GitHub:
• ssh -T [email protected]
• Ref: https://docs.github.com/en/authentication/conne
cting-to-github-with-ssh
• “repo” = repository
• Go to your repositories page:
• https://github.com/yourname

CREATE A NEW
REPO • Click the “New” button
• Create a new repo at GitHub
• On your PC, move existing code directory to a
IMPORT different name, e.g. myproject_orig

EXISTING • Clone the repo to your PC

• Copy all the original code to the cloned repo
CODE TO • Add/Stage, commit, and push all the original
GITHUB files to GitHub
• Optionally, save your “myproject_orig” to an
archive location
• Show current configuration
• git config --global --list
• Modify some configurations:
• git config --global user.name "Sam Noone"
GIT • git config --global

CONFIGURATION
user.email [email protected]
• git config --global core.editor nano
• Alternatively, change your environment
variable VISUAL and/or EDITOR to
“nano” or whatever editor you prefer
• git config --global init.defaultbranch main
• Copy the “ssh” repo link
• In terminal:
• git clone [email protected]:myname/myrepo

CLONE THE
REPO
• Each circle represents a “commit”

DIAGRAM OF
STATE OF
CODE
• Type (or use editor of choice):
• nano hello.py
• Edit
• Save
CREATE A NEW
FILE Contents of file:

#!/usr/bin/env python3
print("hello, world!")
ADD/STAGE • Type:
THE FILE • git add hello.py
• Type:
• git commit
• An editor will launch asking for a commit
message
• Type a brief description of the changes you

COMMIT THE made

• Save the commit message (file) and quit the

CHANGE editor
• N.B. you are committing this change to your
local repository
• Check the repo on GitHub
• Notice that the file is not there
• DEMO
• Type
PUSH THE • git push –u

CHANGE • Check the repo on GitHub

• Notice that the file is now there, with the commit
UPSTREAM message shown
• DEMO
• Now, edit your file and make some changes
• Save the file
MODIFY AN • See a summary of what you have changed:

EXISTING FILE • git diff

• Then: add, commit, push –u
• DEMO
1. Add/Stage file(s) – git add
2. Commit file(s) – git commit
3. Push upstream – git push -u
SUMMARY SO 4. Make changes
FAR 5. Go to 1

Aside: to make shell have git

decorations https://ohmybash.nntoan.com
• Undo an edit which has not been
staged/added
UNDO • git restore .
• git restore path/to/file
• Oops. How to roll back a bad commit?
• Before it has been pushed upstream

UNDO A • Reset to one commit before HEAD:

• Retain changes: git reset --soft HEAD~1
COMMIT • Discard changes: git reset --hard HEAD~1
• Hazard of only working with a single branch
• DEMO
• How to make modular changes to code
without breaking what is already working
• Including fixing bugs
• How to collaborate without stepping on each
other’s toes
• How to get back to a previous working version
BASIC BRANCH • You do not need branch and merge for a very
basic workflow,
AND MERGE e.g., https://uidaholib.github.io/get-
git/3workflow.html
• BUT very useful for “unbreaking” things
• Especially if multiple people are working on the
same code
• More docs: https://git-
scm.com/book/en/v2/Git-Branching-Basic-
Branching-and-Merging
BASIC BRANCH
AND MERGE
• DEMO

BASIC BRANCH
• Create a new branch and switch to it
• Work on new branch

AND MERGE •
•
Compare with main branch
Commit new branch
• Merge new branch into main
• git checkout -b new-feature
• List all branches
• git branch
• Edit new file goodbye.py
• git add goodbye.py
• git commit

BASIC BRANCH • git push –u

• Read error message, and follow directions

AND MERGE • git push --set-upstream origin new-feature

• Go to GitHub

DEMO • Read the message

• Merge the change into main
• git checkout main
• git pull origin main
• git merge new-feature

BASIC BRANCH • git push origin main

• Delete the "new-feature" branch
AND MERGE • Use GitHub on web

DEMO • Command line

• git branch –d new-feature
• git branch (to check)
• Push the change (branch delete) to GitHub
• git push --delete origin new-feature
• Check on GitHub
• To fix a bug, or add a new feature
• Create a new branch and check it out (a.k.a.
switch to the new branch)
SUMMARY SO • Make edits in the new branch and commit as
usual
FAR • Once satisfied (i.e. bug fixed, or feature fully
implemented)
• Merge branch back into main
• Optionally, delete the bug fix/feature branch
• For major or minor “releases”

TAGGING • Known working versions

• Ref: https://git-scm.com/book/en/v2/Git-
Basics-Tagging
• We now have first working version of our
application
• Create an annotated tag
• git tag –a v0.1 -m "First working version 0.1"
• See all tags
• git tag
• Show annotations
TAGGING • git show v0.1
• Push tags to GitHub
DEMO • git push origin –tags
• Look on GitHub
• N.B. you can download a zip or tar.gz archive file
• Branch, add new feature, merge, tag
• Use
gist https://gist.github.com/prehensilecode/c18e
eb5876c6c8b64ec681ad691e6910
• Switch to old tag
• git checkout v0.1
• Tag to mark significant milestones, e.g. releases
• Tags should be applied only to fully working code
(barring any undiscovered bugs)
SUMMARY SO • Tags allow you to “rewind” to a previously
working state
FAR • If bugs are too major to just edit to fix, you can
discard any changes made since a previous tag.
E.g. v1.3 is badly broken, rewind to v1.2 by:
• git checkout tags/v1.2
• Not just a remote Git repository
• Issue tracking
• Bugs
• Feature requests
• Collaboration
• Pull requests – others (may or may not be in
team) can contribute code, and request that the

WHAT GITHUB
owner of the repo pull the change into the
originating repo

ADDS TO GIT • Continuous Integration (CI)

• is the practice of merging all developers' working
copies to a shared mainline several times a day
• Use GitHub Actions:
• https://docs.github.com/en/actions
• https://docs.github.com/en/actions/learn-
github-actions/understanding-github-actions
• e.g. run a test suite (on GitHub serv ers) whenever a
change is pushed
• GitHub Desktop – GUI Application
• https://desktop.github.com/

GITHUB • Available for macOS and Windows only

• GitHub Command Line Interface
CLIENTS • https://cli.github.com/
• Access GitHub functionality from the command
line (I.e. not just another git)
• Do no (or minimal) editing on Picotte
SUGGESTED • Create a GitHub repo (private or public)
WORKFLOW • Edit code on your personal computer

FOR GETTING • Push changes to GitHub

• Go to Picotte
CODE TO • Checkout the repo, and pull any updates, and
PICOTTE run code
• Rinse and repeat
SUMMARY
• Basic source code management with git
• Edit, stage (add), commit, push
• Pull
• Branch and merge
• Tag
• GitHub features
• Workflow suggestion
• Importing existing code to GitHub
• Code editors provide features to aid in
programming
• Syntax highlighting
• Error checking
EDITORS • Etc.
• Extensible
• e.g. Run a Jupyter notebook in a VS Code (or
Emacs) tab
• Support Git and GitHub
• UI to manage entire software projects
• Build and test system
• Debugger

INTEGRATED •
•
Tracing
Version control
DEVELOPMENT • Editors now have some IDE features (see
ENVIRONMENTS previous slide)
• E.g.
(IDES) • Eclipse https://www.eclipse.org/ide/
• NetBeans https://netbeans.apache.org/downloa
d/index.html
• macOS XCode
• Using a separate Git/GitHub application or
command line is a little annoying
• Switch from editing to GH Desktop or terminal to
perform Git operations
EDITOR • Editors for programming almost all have
INTEGRATION integration with Git and GitHub
• Indicators while editing to show state of code
• Perform git operations: add/stage, commit, push,
tag, etc.
• Perform GitHub operations: refer to an issue, etc.
• VisualStudio Code
• Download: https://code.visualstudio.com/
• Free of charge editor from Microsoft
• Runs on Windows, macOS, and Linux

EDITOR • Has Git and GitHub integration

• Git (and other SCM) support built in

INTEGRATION: • But there are other extensions which offer

conv enience functionality

VS CODE • See: https://code.visualstudio.com/docs/edito

r/versioncontrol
• Extensions to install:
• GitLens
• GitHub Pull Requests and Issues
• Etc.
• Sign in to GitHub
VS CODE WITH GIT DEMO
• Emacs is not just an editor
• It is an entire user interface that can replace your
desktop, including shell, email, web browser,
calendar, ipython, etc.
• Because it is a machine which runs apps written
in the Emacs Lisp language

EDITOR • The editor is just the default app running

• Runs both in GUI and in the terminal
INTEGRATION: • Emacs vs Vi(m) is archaic

EMACS • Power users use Emacs with Spacemacs and Vi

key bindings
• Spacemacs
• No funny control sequences, only SPACE
• Discoverable: possible completions shown every
time so you can learn as you go
• GOAL: don’t move hands from keyboard
• vi is a modal editor
• insert mode - where typed text becomes part
of the document
• command mode - where keystrokes are
interpreted as commands that control the
edit session WHAT IS VI
• Command mode allows powerful operations
• Repetitions
• Search and replace
• Etc.
EMACS WITH GIT DEMO
• Git book: https://git-scm.com/book/en/v2
• About version control: https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control
• Branch & merge: https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
• GitHub quick start: https://docs.github.com/en/get-started/quickstart
• Simple git workflows:
• https://uidaholib.github.io/get-git/3workflow.html
• https://www.atlassian.com/git/articles/simple-git-workflow-is-simple
• Another branch & merge tutorial: https://www.atlassian.com/git/tutorials/using-branches
• GitHub CLI (gh): https://cli.github.com
• Oh My Zsh: https://ohmyz.sh
• Oh My Bash: https://ohmybash.nntoan.com
• Visual Studio Code: https://code.visualstudio.com/
• Sublime Text: https://www.sublimetext.com/
• Spacemacs: https://www.spacemacs.org

REFERENCES