Appendices
A
Git and GitHub
Contrary to popular belief, Unix is user friendly. It just happens to be
very selective about who it decides to make friends with.
— Unknown source.
Table A.1: Concepts.
Concept
git versus GitHub § no. A.1.1
Forking on GitHub § no. A.1.1
git clone § no. A.1.3
git commit § no. A.1.4
git pull § no. A.1.5
git push § no. A.1.5
git stash § no. A.1.6
A.1 The Concept of Version/Revision Control
Regardless of whether you use a computer for designing hardware, writing
software, browsing the web, or writing documents, it is often useful to keep
track of different versions of your work. As a result, there are a number of
tools for making keeping track of file versions painless, whether you need to
track revisions of a single document such as a report, or to track the revisions
of thousands of files in a software implementation or hardware design whose
individual versions depend on each other. These tools are called version con-
trol systems (VCSs) or revision control systems (RCSs) and include systems such
as RCS
1
and the proprietary SCCS
2
system used at Bell Labs in the eighties,
1
Tichy
1985.
2
Rochkind
1975.
the open-source CVS
3
system popular in the nineties, and the Subversion,
4
3
Cederqvist, Pesch, et al.
1992.
4
Pilato, Collins-Sussman,
and Fitzpatrick
2008.
Mercurial,
5
and Git
6
open-source VCS systems and many other proprietary
5
O’Sullivan
2007.
6
Loeliger and McCullough
2012.
systems. All version control systems provide a way for you to keep track of
different versions of files without copying files: they typically provide com-
mands to allow you to “tag” the current version of one or more files with a
tag, and to subsequently revert to that version, list the versions of a given file,
etc. The collections of files and the history the version control tools maintain
on them is usually referred to as a repository.
Git and Mercurial are examples of what are commonly referred to as dis-
tributed version control systems (DVCSs): you can keep track of changes even
when not connected to a central server that serves as a common repository.
However, to make it easy for people to share their repositories with others,
there are a number of online services that allow you to make a copy of your
4 phillip stanley-marbell
version control repository available to others. One popular example of such
a service is GitHub.
A.1.1 Git and GitHub are separate things
The program
git runs on your PC and allows you to keep track of versions
or revisions of your files by storing histories of the changes you make to files.
GitHub, on the other hand, is a website that hosts Git repositories. You can
create an account and use it to host copies of your repository to allow you to
collaborate with others.
A.1.2 GitHub online operation: fork
If you will eventually want to compare or contribute changes you have made
to someone else’s repository, it is necessary to have a way to make a copy of
their repository in such a way that you can compare your history of changes
to theirs in a robust way. GitHub provides a method to do this and it is called
forking a repository. Forking a repository is something you do on the GitHub
site and it is not an operation in the
git command line. Find out more about
forking a repository on GitHub online.
A.1.3 Git command line operation:
git clone
Forking a repository online adds a copy of the repository to your GitHub
online account and keeps track of the original repository you forked. To get
the copy you have made online onto your local workstation, you will need to
use the Git command line and the
git clone operation.
A.1.4 Git command line operation:
git commit
Once you have your local clone of the forked repository, you can start making
changes and recording snapshots of your changes using git commit. Impor-
tant: Aim to have at least one
git commit in the forked repository each day to
keep a snapshot of your progress and git push to the corresponding GitHub
account to back up your change history on GitHub. If you fail to do so, you
run the risk of losing all your work when things go wrong. You can have
as many commits as you wish and the more you have the easier it will be to
track down what went wrong when parts of your project stop working. Find
out more about
git commit and git push by browsing the git tutorial online.
We discuss
git push a bit more, below.
foundations of embedded systems 5
A.1.5 Git command line operation:
git pull and git push
Once you have cloned a repository (or cloned the fork of a repository), you
can keep your local clone up to date with the online version using two op-
erations:
git pull to retrieve the latest changes from the version online, and
git push to send any changes you have made (and committed) locally, to the
version of the repository online. Find out more about
git pull and git push
by browsing the git tutorial online.
A.1.6 Temporarily saving your local changes before doing a
git pull, us-
ing
git stash
When you perform a git pull to retrieve the latest changes from the ver-
sion online, the command will need to merge those changes with your local
changes (if any). This typically means you need to perform a
git commit
before performing a git pull. You may however wish to temporarily hide
your local changes, merge in the version from the remote repository, and then
reapply your local changes. The command you use to do this is
git stash:
Before doing a pull, do git stash; after doing the pull, do git stash apply.
Find out more about git stash by browsing the git tutorial online.
