Introduction to Git for Non-Developers

an introduction to
git
(even for non-developers)
john sj anderson · @genehack · os101/columbia • 17 apr 2018
1 — intro to git — os101/columbia — @genehack

vp of tech, infinity interactive
custom software development
and technology consulting
hi, i’m john.
also known as
@genehack

do you identify as a non-developer?
developer? something in between?
no experience with git? some
experience? consider yourself a git
expert?
for those w/git experience, how
many of you are anxious about git?
let’s start out with
an audience
survey3 — intro to git — os101/columbia — @genehack

simplify and de-mystify git
open source desperately needs non-
developer contributions, but git anxiety
can block or slow down otherwise
helpful contributions. i'd like to help
people understand git a little bit better,
to work to reduce that barrier to entry
my goals for this
talk4 — intro to git — os101/columbia — @genehack

going to talk about how you get a git
repository to work on
adding and changing files
sending changes back up to the original
branching and merging
saving your bacon when things go pear-
shaped
additional resources
talkoverview5 — intro to git — os101/columbia — @genehack

this is a tough topic. there's lots of
jargon
i'm going to try to explain things in
different terms than are normally used to
ease that a bit.
trying really hard to avoid saying "just",
"simple", "easy", etc. please help me
here.
ground
rules6 — intro to git — os101/columbia — @genehack

what is
git?7 — intro to git — os101/columbia — @genehack

this definition has the unique
combination of being 100% accurate
and also being completely useless
unless you already know what it means.
so if you don't already know what it
means, you will be forgiven if your
reaction to this definition is ...
distributed
revision
control
system

let's break this down into a
couple of parts. first, let's
consider 'revision control
system'.
what's a revision control
system?
distributed
revision
control
system

revision control systems
(rcs, cvs, svn, tfs, git, etc)
are a fundamental
building block of software development.

<insert rant about how this
stuff should be taught in
school>
a brief
aside14 — intro to git — os101/columbia — @genehack

ok, so that's 'revision control
system' -- what about the
'distributed' part? what's that
mean?
distributed
revision
control
system

another
brief aside

git is a really nice fit for any kind of text-
based stuff that changes over time --
websites, recipes, writing, your resume,
etc.
git will even work okay with binary
formats, it's just a bit harder to see
some of the changes that happen that
way.
git’s not only for
code.18 — intro to git — os101/columbia — @genehack

git is also not
github.19 — intro to git — os101/columbia — @genehack

also not bitbucker, not team
foundation server
all of these are sites that provide
hosting for git-based projects
along with a number of other
project management tools.
git is also not
gitlab.20 — intro to git — os101/columbia — @genehack

they're way bigger than the scope of
this talk, and the material in this talk
applies equally to any of them. i
encourage you to initially focus on
learning the basics of git, and only
then start to focus on the git hosting
site you (or the project you've chosen
to work on) have decided to use.
learning the basics
of git will help you
regardless of what git hosting is used

so, one of the initial things you
need to do, if you don't already
have git installed, is to get git.
getting
git22 — intro to git — os101/columbia — @genehack

you can do this by going to git-
scm.com...
note that i will put these slides up
for download after the talk, and
tweet out the location, so you
don't need to worry about writing
down each url...
git-scm.com

where they will have links to install it for
whatever platform you're on.
if you're running something with a
package manager (linux, mac with brew,
etc.) just using the package manager
may be easier.
you may also see that they have links
here to 'Mac GUIs'...

...so this is a good time to talk about GUI git versus CLI git.
after thinking about this for a bit, i decided to give all the
examples in this talk in terms of the CLI. that was for a few
reasons:
when you need to do a net search for help with something,
most of the results will be given in terms of the CLI, so having
a basic understanding will help
showing a GUI in addition to the CLI examples would
effectively halve the amount of stuff i can get through (and the
talk is already groaning when jammed into a 30 minute slot)
there are a bunch of Git GUIs and this way i didn't have to pick
just one to show
cli
versus
gui25 — intro to git — os101/columbia — @genehack

aside: if you're not familiar with the CLI,
it's a useful skill to have as an open
source contributor, even as a non-
developer. Tracy Osborn, who has
done some nice intro web design and
web programming books, just recently
released a free e-book called "really
friendly command line intro"
26

you can grab a copy here --
and again, slides available
online later, so you don't have
to copy this down.
hellowebbooks.com/learn-command-line
27

before we do anything else,
we need to tell git
who we are

git config is a git command for modifying
configuration values. in this case, we're giving it the --
global flag to indicate that we want to modify the
configuration for any use of git. and then we set the
user.name and user.email values to our name and email.
this information is needed because once we start
making changes (here in a few slides), git is going to
track who made what change. if you don't provide these
values for it, sometimes git will try to guess, and it will
probably get it wrong. (and when it doesn't guess, it will
just refuse to work until you run the above commands.)
git config --global user.name "Put your name here"
git config --global user.email "email@example.com"

now that we've got the
required git configuration
done, we need to get a
repository to work on.
step one: obtaining a
repository

oh, wait, there's some jargon. what's a
"repository"?
a repository is just what git calls a
project, or a directory where the
contents are under the control of git
you'll also hear people say "repo"
because "repository" is an annoyingly
long word to have to type out a bunch
jargon:
repository31 — intro to git — os101/columbia — @genehack

'clone' is what git calls making a copy
of somebody else's existing repository.
this is typically what you'll do if you
want to contribute to an open source
project -- you'll make a clone of the
project's repo so that you can look at
what's there, and possibly change it
and contribute it back to the project.
ﬁrst option:
clone32 — intro to git — os101/columbia — @genehack

this is the github page for an
open source project -- one
that happen's to be one of
mine, a perl module for
interacting with git. if you click
this green button here...

...you'll get a little popup with a
URL you can copy...

...and in fact this little circled
button here does just that,
copies the URL to the
clipboard for you.

then you can open up a
terminal and run the following
command to clone the
repository
git clone <url>

and here's the output you'll see
when you do. this first line tells you
it's cloning into a directory named
'Git-Wrapper' in the current
working directory, and the other
lines here are just stats about the
size of the repository, basically.
$ git clone https://github.com/genehack/Git-Wrapper.git
Cloning into 'Git-Wrapper'...
remote: Counting objects: 4067, done.
remote: Compressing objects: 100% (23/23), done.
remote: Total 4067 (delta 16), reused 33 (delta 16), pack-reused 4028
Receiving objects: 100% (4067/4067), 3.20 MiB | 5.80 MiB/s, done.
Resolving deltas: 100% (1917/1917), done.

the other option for getting a
repository is to create a fresh,
new empty one
second option:
diy38 — intro to git — os101/columbia — @genehack

you do that with the 'git init'
command. it will create a new
repo in a directory named for
the project
git init <project-name>

so, as you can see here, when we run the
command, it creates the directory for us
the directory contains only .git
.git contains a bunch of stuff
you can ignore all of this for the moment, but you
need to understand that the .git directory is where
git stores all the data about the repository itself. if
you remove the .git directory, you turn the repo
into just an ordinary directory containing files.
$ git init my-new-project
Initialized empty Git repository in /Users/genehack/my-new-project/.git/
$ ls -a my-new-project
./ ../ .git/
$ ls -a my-new-project/.git
./ ../ HEAD branches/ config description hooks/ info/ objects/ refs/

ok, now we have a repo! yay!
ok, now we have a
repo41 — intro to git — os101/columbia — @genehack

let's keep working with the fresh new empty repo.
the first thing we need to do is add a file to it.
let's add a README file with some basic info about
the project
README files are traditionally found in the top level
of a repository and contain basic introductory
material about the project -- what problems it aims
to solve, how to use it, maybe instructions on how
to contribute back to the project, etc.
so let's make that file...
let’s
add a ﬁle
to it42 — intro to git — os101/columbia — @genehack

yes, yes, i'm an emacs user.
so, let's pretend we write some
basic stuff in the README.md and
save it
photo credit: https://
www.flickr.com/photos/rore/
4457009838 (cc/by/2.0)
emacs README.md

we need to ask git what's
going on with the repository.
the way we do that ...
next, we need to ask git
“sup?”44 — intro to git — os101/columbia — @genehack

...is with a command called
git status
git status

when we run git status, we see that
git is telling us, "hey, there's this file here,
but you haven't told me to track it or
anything -- just letting you know, i see it"
git also helpfully tells you, "hey, if you
want me to be be tracking it, you need to
git add it"...
$ git status
On branch master
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
README.md
nothing added to commit but untracked files present (use "git add" to track)

so let's run that command
next, git add
git add README.md

and then check the status
again
git status

and now we can see git is
telling us, "yo, got a new file
here!"
$ git status
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: README.md

if you look at the
documentation for git add,
you'll see something like this:
<read slide>
git add
stages
changes to be committed

there's another piece of jargon
to break down -- "staging
area" "
jargon:
staging area51 — intro to git — os101/columbia — @genehack

you can even see here, in the
git status output, git is
telling us how to "unstage"
something
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: README.md

to get this jargon, you need to
understand the different states
git thinks files can be in, or the
lifecycle that a file moves
through
the lifecycle of ﬁle changes
according to git

as we saw, when we create a
new file, it ends up in a state
called "untracked".
untracked
staged
committed54 — intro to git — os101/columbia — @genehack

and git add is what takes us out of that
"untracked" state, and puts us into "staged".
"staged" is an area in between 'untracked'
and 'committed', which allows you to build
up what's going to be in a commit piece by
piece. this isn't something you'll care too
much about when you're just getting
started.
‘git add’ takes you
from “untracked” to
“staged”55 — intro to git — os101/columbia — @genehack

so how do we go
from “staged” to
“committed”?

git commit

the commit message is going to
describe what's in the commit, and
possibly why the change is being made
this is the part where your name and
email address -- the stuff we fed into
git config way back when --
comes into play
git wants commits to
have an accompanying
commit message

by default, cli git uses
vimto write commit messages

https://twitter.com/
thepracticaldev/status/
747871086478516226?
lang=en
if you’re not already
a vim userthis is probably not what you want.

instead you can use the -m
flag and give the commit
message as part of the
command
git commit -m "<your message here>"

to review, git add...
git add takes ﬁles
from “untracked”
to “staged”

...and git commit
git commit takes ﬁles
from “staged”
to “committed”

so that covers adding a file to
the repo. what if we need to
revise it?
so, what about
edits?64 — intro to git — os101/columbia — @genehack

pretend we edit the file again,
and ...
emacs README.md

we ask git, "sup?"
git status

and we see something new!
git tells us the file has been
modified
$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: README.md
no changes added to commit (use "git add" and/or "git commit -a")

so let's return to our lifecycle...
the lifecycle of ﬁle changes
according to git

...and we need to add a fourth
state, modified. so we have
untracked, staged, committed,
and modified.
untracked
staged
committed
modiﬁed

you might wonder, since git
knows the file is changed, can
it tell you how it was changed?
can we ask git
“yo, what changed?”

and yes, it can, with a
command called 'git diff'.
git diff

<briefly walk through diff>
$ git diff
diff --git a/README.md b/README.md
index bf3d7ca..9a71af8 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,3 @@
# My Awesome New Project
+
+**FIXME:** write README

at this point, to get the changes to
README.md committed, you're
going to do the exact same steps as
with adding the file for the first time:
you're going to use 'git add' to stage
the change, and then you're going
to use 'git commit' to commit it.
adding and editing ﬁles is
notvery different73 — intro to git — os101/columbia — @genehack

first we stage the changes
git add README.md

and then we commit them
git commit -m "<explain the change>"

git records the commit messages and then
lets you look back at them. this is called the
'history' of the repository.
when you're first getting involved with a new
open source project, taking some time to read
over the recent history of the repo is a great
way to get up to speed -- you'll see which
files have changed recently, and see who's
actually doing the work to put in the changes
so, what's going on with those
commit
messages?76 — intro to git — os101/columbia — @genehack

the way you look at the history
is with a command called git
log. running it ends up
looking like this:
git log

$ git log
commit f2645941f26ab276bed99b12f170e97ca9c90106
Author: John SJ Anderson <john@genehack.org>
Date: Sat Apr 14 17:04:36 2018 -0400
Update README with FIXME
commit 3e805602660713b8f98f610cf178df70c2ceb91f
Date: Sun Apr 15 07:00:14 2018 -0400
Add README.md

you can also include the -p
flag -- for patch -- to ask git
to show you the exact lines
that were changed in each
commit. that looks like...
git log -p

$ git log -p
commit f2645941f26ab276bed99b12f170e97ca9c90106
Date: Sat Apr 14 17:04:36 2018 -0400
Update README with FIXME
index bf3d7ca..9a71af8 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,3 @@
# My Awesome New Project
+
+**FIXME:** write README

commit 3e805602660713b8f98f610cf178df70c2ceb91f
Date: Sun Apr 15 07:00:14 2018 -0400
Add README.md
new file mode 100644
index 0000000..bf3d7ca
--- /dev/null
+++ b/README.md
@@ -0,0 +1 @@
+# My Awesome New Project

a few more
concepts

branches

a branch is
a new working copy
of your repo

branches allow you to make
changes
without altering the underlying
master copy85 — intro to git — os101/columbia — @genehack

when the work on the branch passes review,
you need to
merge86 — intro to git — os101/columbia — @genehack

pushing

pushing means
sending changes
to some other copy
of the repository

the repository you're
pushing changes to is called a
remote89 — intro to git — os101/columbia — @genehack

pull request

a request to merge
your changes into
their repository

what to do when things go
bad

two ﬁxes that
(almost) always
work93 — intro to git — os101/columbia — @genehack

the first approach is good when you've
got things into a bad state and you
think you know the fix but are worried
that you're going to mess things up
worse: make a copy, try the fix on the
copy, and then if it works, do it to actual
directory. (and if it fails, throw away the
copy and try something else!)
one:
make a copy of your repo
& try a ﬁx
on the copy

if you have modified files in the "bad" copy, don't
forget to copy those out and into the newly cloned
copy
i'm a fairly sophisticated git user. i've been using it for
over 10 year, have given multiple conference talks on
git, have led trainings on git, and i've managed to
screw things up in a repo so badly that i've done this
"just re-clone it" more than once in the last year.
there's no shame in doing this; sometimes things just
get so bollixed up that it's easier to start over than to
unbollix them.
two: rename your repo directory
(from ‘repo’ to ‘repo.bad’)
and then re-clone the repo

review

git status

git add

git commit

git diff

git log

additional
resources

git-scm.com

hellowebbooks.com/learn-command-line

try.github.io

git-scm.com/book

thanks

os101organizers108 — intro to git — os101/columbia — @genehack

you!109 — intro to git — os101/columbia — @genehack

interested in an
internship?
iinteractive.com/internship

Introduction to Git for Non-Developers

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Introduction to Git for Non-Developers

Similar to Introduction to Git for Non-Developers (20)

More from All Things Open

More from All Things Open (20)

Recently uploaded

Recently uploaded (20)

Introduction to Git for Non-Developers