Git is a revision control system that is used for many Open Source projects. Having a basic understanding of Git is essential being able to join an Open Source project and become a contributor. It's also super useful for many other activities! This talk will explore the basics of Git, assuming no existing background experience. Via analogies to other, familiar technolgies, the basic principles of using Git will be explained in an approachable, understandable fashion. People who attend this talk should come away ready to make an initial contribution to an Open Source project, and will leave with a list of additional resources to explore to learn more.
(Genuine) Escort Service Lucknow | Starting ₹,5K To @25k with A/C 🧑🏽❤️🧑🏻 89...
Introduction to Git (even for non-developers)
1. an introduction to
git
(even for non-developers)
john sj anderson · @genehack · dc-baltimore perl workshop · 6 apr 2019
1 — intro to git — #dcbpw 2019 — @genehack
2. vp of tech, infinity interactive
custom software development
and technology consulting
hi, i’m john.
also known as
@genehack
2 — intro to git — #dcbpw 2019 — @genehack
3. 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 — #dcbpw 2019 — @genehack
4. 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 — #dcbpw 2019 — @genehack
5. 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 — #dcbpw 2019 — @genehack
6. 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 — #dcbpw 2019 — @genehack
8. 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
8 — intro to git — #dcbpw 2019 — @genehack
11. 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
11 — intro to git — #dcbpw 2019 — @genehack
13. revision control systems
(rcs, cvs, svn, tfs, git, etc)
are a fundamental
building block of software development.
13 — intro to git — #dcbpw 2019 — @genehack
14. <insert rant about how this
stuff should be taught in
school>
a brief
aside14 — intro to git — #dcbpw 2019 — @genehack
15. ok, so that's 'revision control
system' -- what about the
'distributed' part? what's that
mean?
distributed
revision
control
system
15 — intro to git — #dcbpw 2019 — @genehack
18. 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 — #dcbpw 2019 — @genehack
20. 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 — #dcbpw 2019 — @genehack
21. 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
21 — intro to git — #dcbpw 2019 — @genehack
22. 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 — #dcbpw 2019 — @genehack
23. 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
24. 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'...
25. ...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 — #dcbpw 2019 — @genehack
26. 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
27. 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
28. before we do anything else,
we need to tell git
who we are
28 — intro to git — #dcbpw 2019 — @genehack
29. 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"
29 — intro to git — #dcbpw 2019 — @genehack
30. now that we've got the
required git configuration
done, we need to get a
repository to work on.
step one: obtaining a
repository
30 — intro to git — #dcbpw 2019 — @genehack
31. 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 — #dcbpw 2019 — @genehack
32. '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.
first option:
clone32 — intro to git — #dcbpw 2019 — @genehack
33. this is the github page for an
open source project -- one
that happens to be one of
mine, a perl module for
interacting with git. if you click
this green button here...
35. ...and in fact this little circled
button here does just that,
copies the URL to the
clipboard for you.
36. then you can open up a
terminal and run the following
command to clone the
repository
git clone <url>
36 — intro to git — #dcbpw 2019 — @genehack
37. 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.
37 — intro to git — #dcbpw 2019 — @genehack
38. the other option for getting a
repository is to create a fresh,
new empty one
second option:
diy38 — intro to git — #dcbpw 2019 — @genehack
39. 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>
39 — intro to git — #dcbpw 2019 — @genehack
40. 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/
40 — intro to git — #dcbpw 2019 — @genehack
41. ok, now we have a repo! yay!
ok, now we have a
repo41 — intro to git — #dcbpw 2019 — @genehack
42. let's keep working with the
fresh new empty repo. the first
thing we need to do is add a
file to it.
...but first let's talk about the
lifecycle of files according to git
let’s
add a file
to it42 — intro to git — #dcbpw 2019 — @genehack
43. here are the different states git
thinks files can be in, or the
lifecycle that a file moves
through
the lifecycle of file changes
according to git
43 — intro to git — #dcbpw 2019 — @genehack
44. when we create a new file, it
ends up in a state called
"untracked".
untracked
staged
committed44 — intro to git — #dcbpw 2019 — @genehack
45. so, let's add a README file
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 file
45 — intro to git — #dcbpw 2019 — @genehack
46. 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
46 — intro to git — #dcbpw 2019 — @genehack
47. we need to ask git what's
going on with the repository.
the way we do that ...
next, we need to ask git
“sup?”47 — intro to git — #dcbpw 2019 — @genehack
48. ...is with a command called
git status
git status
48 — intro to git — #dcbpw 2019 — @genehack
49. 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)
49 — intro to git — #dcbpw 2019 — @genehack
50. so let's run that command
next, git add
git add README.md
50 — intro to git — #dcbpw 2019 — @genehack
51. and then check the status
again
git status
51 — intro to git — #dcbpw 2019 — @genehack
52. 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
52 — intro to git — #dcbpw 2019 — @genehack
53. if you look at the
documentation for git add,
you'll see something like this:
<read slide>
git add
stages
changes to be committed
53 — intro to git — #dcbpw 2019 — @genehack
54. there's another piece of jargon
to break down -- "staging
area" "
jargon:
staging area54 — intro to git — #dcbpw 2019 — @genehack
55. 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
55 — intro to git — #dcbpw 2019 — @genehack
56. 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”56 — intro to git — #dcbpw 2019 — @genehack
57. so how do we go
from “staged” to
“committed”?
57 — intro to git — #dcbpw 2019 — @genehack
59. 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
59 — intro to git — #dcbpw 2019 — @genehack
60. by default, cli git uses
vimto write commit messages
60 — intro to git — #dcbpw 2019 — @genehack
62. instead you can use the -m
flag and give the commit
message as part of the
command
git commit -m "<your message here>"
62 — intro to git — #dcbpw 2019 — @genehack
63. to review, git add...
git add takes files
from “untracked”
to “staged”
63 — intro to git — #dcbpw 2019 — @genehack
64. ...and git commit
git commit takes files
from “staged”
to “committed”
64 — intro to git — #dcbpw 2019 — @genehack
67. offers easier, more flexible
committing. also refines the
branching model to be a bit
more intuitive
anybody already using gitless?
maybe check out
gitless
(gitless.com)
67 — intro to git — #dcbpw 2019 — @genehack
68. so that covers adding a file to
the repo. what if we need to
revise it?
so, what about
edits?68 — intro to git — #dcbpw 2019 — @genehack
69. pretend we edit the file again,
and ...
emacs README.md
69 — intro to git — #dcbpw 2019 — @genehack
70. we ask git, "sup?"
git status
70 — intro to git — #dcbpw 2019 — @genehack
71. 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")
71 — intro to git — #dcbpw 2019 — @genehack
72. so let's return to our lifecycle...
the lifecycle of file changes
according to git
72 — intro to git — #dcbpw 2019 — @genehack
73. ...and we need to add a fourth
state, modified. so we have
untracked, staged, committed,
and modified.
untracked
staged
committed
modified
73 — intro to git — #dcbpw 2019 — @genehack
74. 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?”
74 — intro to git — #dcbpw 2019 — @genehack
75. and yes, it can, with a
command called 'git diff'.
git diff
75 — intro to git — #dcbpw 2019 — @genehack
76. <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
76 — intro to git — #dcbpw 2019 — @genehack
77. 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 files is
notvery different77 — intro to git — #dcbpw 2019 — @genehack
78. first we stage the changes
git add README.md
78 — intro to git — #dcbpw 2019 — @genehack
79. and then we commit them
git commit -m "<explain the change>"
79 — intro to git — #dcbpw 2019 — @genehack
80. 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?80 — intro to git — #dcbpw 2019 — @genehack
81. the way you look at the history
is with a command called git
log. running it ends up
looking like this:
git log
81 — intro to git — #dcbpw 2019 — @genehack
82. $ 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
Author: John SJ Anderson <john@genehack.org>
Date: Sun Apr 15 07:00:14 2018 -0400
Add README.md
82 — intro to git — #dcbpw 2019 — @genehack
83. 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
83 — intro to git — #dcbpw 2019 — @genehack
84. $ git log -p
commit f2645941f26ab276bed99b12f170e97ca9c90106
Author: John SJ Anderson <john@genehack.org>
Date: Sat Apr 14 17:04:36 2018 -0400
Update README with FIXME
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
84 — intro to git — #dcbpw 2019 — @genehack
85. commit 3e805602660713b8f98f610cf178df70c2ceb91f
Author: John SJ Anderson <john@genehack.org>
Date: Sun Apr 15 07:00:14 2018 -0400
Add README.md
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..bf3d7ca
--- /dev/null
+++ b/README.md
@@ -0,0 +1 @@
+# My Awesome New Project
85 — intro to git — #dcbpw 2019 — @genehack
101. 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 fix
on the copy
101 — intro to git — #dcbpw 2019 — @genehack
102. 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
102 — intro to git — #dcbpw 2019 — @genehack