Tip:
Highlight text to annotate it
X
♪ [music] ♪
[GitHub: Social Coding]
[History and Collaboration with Git and GitHub]
[The Essentials of Git Log and Teamwork]
[Brent] Hi, this is Brent Beer, and this is a presentation I had done previously
over Git Log and some of its essential flags,
as well as Collaboration up on GitHub.
So with that, let's get right into it.
So that's Git Log without any additional action flags,
and we get just a slew of commits here
with a little bit of data in each one of them.
Now, you may notice on the bottom of my screen,
if you haven't seen this before, it's actually piped
into a command called, "more,"
so, I can scroll up and down with J and K.
I can't scroll down with my mouse,
doesn't go anywhere,
so you have to use J and K to actually move
throughout that,
but that can be a little overwhelming.
Clearing my screen real quick.
If there's a lot of commits
in a repository that you haven't seen before,
you need a way of just viewing different commits,
and one way we can do that,
[hard keystroke]
is just with a dash and then a number.
So, this number can be anywhere from one 'til 100 if you really need it to,
or if there is really 100 commits in your repository.
This is simply an upper bound.
So, oftentimes,
I'll just say five,
Now, I filled out my screen, okay. But we want to see just two.
I'll clear my screen, give you a better idea of that.
It just limited it to just two.
So, that's one way we can get a better idea
of the way things are going,
and how many commits we're actually going to be looking at.
So, again, these numbers just specify the number of commits
we'll end up seeing total, so, six.
You can scroll down a little bit, but it will stop us after six.
And, Q to get out of that.
[hard keystroke]
So, secondly, when we're looking at these commits, there's a little bit
of information in each one.
There's a hash specifying this specific command,
the author and a date, and then a little bit of information here.
And if you notice that, there's actually other ways to view this information,
one of which is with the --pretty command.
So pretty is simply a formatting tool,
and it has a number of different formats it can actually be in.
That are actually in my lesson plan notes
if you want to take a look at all of them.
I'm going to only be showing a few of them here.
So, one of my favorite though, is this oneline command.
I'm actually going to use this in correlation
with the previous numbers with those dashes.
So, we say "git log -2 --pretty=oneline"
We get really simple commits,
and all we see here is the hash,
and then the subject line.
Now, in a commit message itself,
there's actually generally
in good form, or clean form,
it's sometimes suggested to have a subject line
and then a body of a message afterwards,
kind of like you're writing an email. [presses enter key]
And we can actually get a look at that
if we just look at git log --pretty=medium.
So medium is actually the default for git log,
and if we scroll down a bit, we can actually see
when we have a pull request that's been accepted from GitHub,
which is one of these. We can see that this line here is the actual subject
with the additional body of the text actually here.
So, this is the little bit of the text we don't see when we do the oneline,
and, I guess that's part of the reason why, by default
--pretty=medium is the default output.
But, one of the last things
I want to show is there's actually "full" and "fuller."
I particularly like fuller because it gives
kind of a nice idea of
this author date, and commit date.
Now generally, those are about the same,
but when you start working with an external site like GitHub,
and you send a pull request,
you can actually see that, as we see right here,
that we have a different author date than a commit date,
and that's just because I had actually made this commit on the 21st,
and we see here from this merge command on the 23rd that
that is when is was actually pulled in to the commit.
So, by default the date that is shown
when we do --pretty=medium
it's actually that author date.
[Matt] So Brent, I think that's a really interesting point,
if I could just ask one question,
as I was
[Brent] Yeah.
[Matt] learning Git.
So I heard you say
that most of the commits are going
to have the same date for the author and the committer,
it's when someone kind of performs a second activity on the commit,
[Brent] Right.
[Matt] putting it some other place,
or folding it in with the merge, or cherry picking,
- or rebasing-- - Yeah.
[Matt] If I heard you right,
those are the activities that will change one of those two fields,
so that we can see both. Is that right?
[Brent] Yeah, exactly. And, I didn't find any
in the actual teach.github.com repository,
but the actual committer and author could even be slightly different,
and GitHub has a really cool way of showing that as well.
Unfortunately, I don't have planned a show of that,
but, like you said, the cherry pick and the different commands like that
with doing a pull request on a merge, like that,
you can often get a different commit date than your actual author date.
[Matt] And the point of that is, just to make sure I understand,
to close out that is,
the reason you want to do that is,
who wrote it, you might ask them
- a question-- - Right.
[Matt] and who brought it in,
because you might want to ask them
a different question.
- So, so-- - exactly.
[Matt] "Brent, why did you write the algorithm that way?"
or, "Tim, why did you ship this feature?"
Those are very discreet questions, right?
[Brent] Right. So it's all about knowing kind of where all of this happened,
who on your team was responsible,
not necessarily in a bad way, but, who can you either
pat on the back, or say,
"Thanks for the help on that. You brought it in. I wrote it.
Now, that's good team work."
So, it's this trail of actually knowing
where things came from, and when things came from in a historical purpose.
And, I'm glad you actually mentioned, you kind of hinted towards filtering
of author and knowing who did something,
and that's great timing to my actual next point
is with Git log,
you can actually see who the author is
by specifying the author flag.
So, for our purposes of this exercise,
I'll go ahead and narrow it down
to my own username,
and when we do it in this sense,
when we use four to number the limit, limit the number of commits we see
with the author, we'll actually see four commits that only I have authored.
So, when we do that,
we see the dates jump a little bit more,
a little bit further in the past
than if we would say something like, "Tim,"
we'd actually see [strikes the enter key hard]
[strikes the enter key hard]
We'd actually see the most recent commit,
and then some other commits
that Tim has added on.
So, beginning of filtering down our actual material,
our commits that we actually look at,
we can filter by this specific author.
So, we can use that, also in conjunction with,
[strikes many keys] skip over to Matthew here,
with conjunction with the --grep command.
So, --grep itself, if any of you are actually familiar,
is a way of just grabbing different expressions.
So generally, those expressions will be words or phrases that we can look for,
and, these phrases aren't in the actual content themselves,
they're in the message.
So, I think that's very important to realize here, as we look at
the actual message of a commit,
and it's different levels,
the subject, and the body of the message,
we can actually --grep
for different things in the actual body.
So, one thing to look at is,
maybe you want to see
merge commits come in from GitHub in a particular format
with the word "merge."
So, we want to be explicit, [taps enter key hard] we can say, "merge."
So, all the commits start with a merge word right here.
We can actually search through on that.
Now, if we look at this commit right here,
we see the word "updated."
But it's not in the actual subject itself,
so when we're grepping for this,
if we want to see commits that,
we know there is a word
in the message somewhere,
but it might not necessarily be in the subject, if using our --pretty format
we actually did our oneline, looking for the word "updated,"
we can actually see that this commit will still show. [presses enter key hard]
So here's the commit to the d60d0,
and although this subject does not include the word "updated,"
the commit itself in its message actually has the word "updated."
I it's pretty important to point out that --grep itself doesn't just look at
the format of the message that could be returned from the commit,
but the entire commit message itself.
So, you already know this commit has that word in it in the message,
but you don't really care to see all of it.
You can just do it, and the different --pretty format to get an idea of
how things are going.
So, Matthew, anything to add with that?
Have you found any good uses
of the --grep command in your past
that you've had to take a huge advantage of?
[Matt] Oh absolutely, and in fact,
just to give a practical sense
to the skills that you gave folks here,
I used to be the human filter
back in ClearCase and Subversion and stuff,
to go back and find these things.
Where was that
- commit-- - Right.
[Matt] that I had a ticket number, for example, in?
Where did I remove this variable or this constant?
And instead, what I would like folks to start thinking about
is having the tool do that heavy lifting for them.
using what
- exactly - right.
[Matt] you're showing them, they should be asking the tool to find the commits
that equate to where Matthew, where has this word, where in the last several weeks
in all these constraints that you're giving us.
[Brent] Yeah.
And I think that, like you said,
have the tool do the work for you.
You have a little bit more experience
with Subversion, and ClearCase than I do,
but if you know there's a specific word
or phrase, and a message
that you're actually looking for,
it's really great to just be able to have
Git Log actually look that up for you.
So, with that being said, there's another filter command
that I want to touch upon called "--since."
Now, just like you would expect
"--since" will read pretty well on English, so you can actually say,
--since="two weeks ago"
And I think this could be really important
because maybe this time frame is actually
how long you were on vacation,
or how long since there's been some, [clears throat] excuse me,
how long since there's been any big changes with your repository,
so when you do that, since I've updated my report, there's only been a number of
commits that have been added in,
we can actually change this to be "1 month ago", [presses enter key]
[presses key] or, "2 months ago" [strikes enter key twice hard]
and just get more information that way.
[Matt] And, you know, Brent,
since so many shells, I like how Git kind of thinks about,
"Oh. Think of the developer."
And you wrapped that nicely in quotes,
- and as you said, - Right.
[Matt] it reads well in English.
I love the fact that since we as developers often are annoyed
by wrapping things in quotes, it'll also allow for a dot, a period,
in between each of those words.
- [Matt] And you can strip off - [Brent] Right.
[Matt] the quotes too.
So, equivalent, exactly the same thing what you just showed us,
but I always like pointing out, the alternate forms like,
"Really? Like, "quotes, dash, dash, since, two dot months dot ago."
And that'll be the same.
[Brent] Yeah.
And, working on that, there's actually another format that you can use,
when even looking at this particular branch, you do a quick git status,
we can see
that I'm on the gh-pages branch, and we can actually use log to,
in a format very similar to what you're talking about,
compare the branch. pages@, and then, {2.weeks.ago}- --
and we can actually use this triple dot comparison
to say, gh-pages
Now, it looks a little weird,
it might be a little hard to read.
You can actually use this in a GitHub URL,
which I may show a little bit later.
But, the way this will actually work is,
we want to say,
"What does gh-pages have now that it didn't have two weeks ago?"
So it's a little reverse ordering,
if we do this,
so, let's change that a little bit.
Let's just change it with a few days here.
- [Matt] Two days ago,-- - [Brent] So we see here.
- [Matt] or something like that?-- - [Brent] Yeah. Yeah, exactly.
[key getting stuck]
[Matt] Only goes back to Monday, the third of December.
Look at shallow that is.
You're just on the cutting edge.
One 24 hours ago.
- [Matt] That's always-- - [Brent] Interesting.
- [Matt] a fun one. - [Brent] So, yeah.
[Matt] You got such a shallow
- history on this one - [Brent laughs]
- [Brent] Yeah, so-- - [Matt] 24
[Brent] That's a weird formatting,
so one thing we can actually do is,
compare this to another branch.
See, might get branches here.
[Brent] So,
[Matt] List those out, yeah?
[Brent strikes enter key]
- [Matt] Okay that's-- - [Brent] Yeah.
[Matt] the good old,
"Okay, what do you have? Alright I like it."
[Brent] Right. So, one thing we can use,
instead of a time format
with the @, we can say what is in this collaboration-testing branch,
which we'll see very shortly [strikes enter key hard]
that is not in our actual branch here.
So, maybe I want to see, what kind of commits
happened on a branch that I was gone for.
So we can actually look back in time and view those specific commits.
So, it looks like there's only one, two, three, four commits
that have come through on this collaboration-testing branch
I may have missed from the gh-pages branch.
- [Matt] Interesting.-- - [Brent] So,
So you're comparing, what I see there, is you're comparing
one branch against the other,
so rather than worrying about time,
you're kind of asking the question,
"What does one have that the other does not?"
[Brent] Exactly. So we're comparing
this collaboration-testing branch
to gh-pages branch.
What is in here that is not in here.
And this is actually also done on GitHub.
I'll just type the command down in terminal here.
You can type it in the notes as well.
It's actually just--Well, here, let's do a quick toss over to that.
We actually want to see this we can say, "compare,"
which works out a bit better
than just the the log.
gh-pages_collaboration-testing [hits enter key hard]
- [Matt] Oh wow, so-- - [Brent] So--
- [Matt] the same syntax-- - [Brent] same commits,
[Brent] brought in the exact same way.
[Matt] So, wow. I'm,
- [Matt] revelation-- - [Brent] So.
here for a second. Grab me
- that URL if you will. - [Brent laughs]
- [Matt] So the-- - [Brent] Yeah.
[Matt] same syntax, if I learn it from the command line,
because, I'm always getting these questions from my students,
"Alright. I'm not really
- [Matt] a big fan of-- - [Brent] Right.
[Matt] command line. So, if I learn this syntax,
you're telling me that I can do the same thing
in the URL, and get GitHub to render it?
[Brent] Yep, the only trick is,
on your specific repository, have to say "compare."
It's not "log" and then "branches,"
it reads more like English.
You want to compare
these two branches together.
So, just a quick toss over to this exact path,
same command except, away from the command line,
but actually just on GitHub is this compare feature.
- [Brent clears throat] - [Matt] I like it.
[Matt] And, you know, I'll throw in there too, Brent,
and I'll put it over in the chat window in a second,
that the Hub command from the command line
- [Matt] Has a-- - [Brent] Yes!
comparison that will launch those URL's.
I think that's
- [Matt] kind of a neat bridge. - [Brent] Awesome. Yeah.
[Matt] [inaudible]
[Brent] Yeah, the hub command is quite a neat tool itself.
I had that on my laptop,
but not on this instruction computer.
So, with that, let's dive a little bit more into--
[clears throat] some content. Excuse me.
So, up 'til now, we've seen ways of filtering,
just looking at pure commit messages,
changing the level of detail that might be in them,
or filtering them down to see only author, or a given expression that you know about,
But, let's actually fuse some given content.
So, I'm going to go ahead and use some of the commands previously talked about.
-1 and the --author flag.
So were going to be looking at my latest commit.
As we look at it here, we see
"fixed layout to work with title refactor,"
That doesn't--That's great.
I know what that commit certainly entitles,
or has in it.
And, Tim and Matthew may also as well,
but, to give just a better
a slight glimpse into what that has,
we can use the --stat command.
Now, --stat is just going to give us
this heads up into
how many files were changed,
how many total insertions,
total deletions, and what specific file.
So, this can be super useful
if we're not limiting to just one commit,
but a number of commits.
We can see I had a pretty big commit
back on the 21st
where I removed one or two lines from many, many files
So, [strikes key] that's pretty important for knowing possibly what commit
you need to dive deeper into.
So, start with a very basic view of just seeing all the commits,
narrow it down to the author, narrow it down to high-level stats about it.
What if you actually wanted to view that specific commit,
and all of its changes itself?
To do that you would simply use the -p operator.
Now if you guys [taps key hard] may have used git before,
depending on the spread
of knowledge within the class,
-p is just going to commit a patch for us.
So, this bit all down here, down to here, is simply a patch.
So, git's way of saying I have this one file and a B, second file,
and comparing the two of them here, I think with the -p, it really gives you
a better idea of,
the exploratory nature of
what had happened at previous commits.
So, if wanted to, [strikes key hard]
We could actually save my last two commits.
This will give us those one or two-line changes that I've made previously,
as I scroll through this.
I'm not going to bore you with too much scrolling,
but you can see that there is just one or two lines changed
about which lines they were changed at.
And so, we can see that it was originally six to eight.
Now it's just six because there's no lines there anymore,
and here's the actual full length of the file itself.
Now, as we look at that very first commit,
we may see [strikes key hard]
there's a little bit of similarities between these first two lines.
We see this little bit here,
and it seems like
it is only tracking the entire file changes.
Excuse me.
Though that's not entirely true.
We can tell git to say,
"Although you're showing me the full patch,
why don't we just watch the specific words?
that have changed?
So don't show me just entire lines,
show me words.
So, we use --word-diff to do that.
If we see, git starts not tracking entire things,
and it uses the syntax with the brackets.
So we can see a red bracket.
I have colors turned on.
But, you can see a bracket
with a minus sign for content
that was removed,
and then no color for content that did not change,
and then new content.
So, we remove that word-diff,
we can see a little bit more lines than are actually shown.
See that? It looks like
this entire line was removed,
and this entire line was added,
but really, the only part that was added
was this end bit here,
and a bunch of additional section removed.
[Matt] And, Brent, you know what I think is interesting is,
why does it use those symbols when you just did the word-diff from a second ago?
The short story to that is that those are very parsible
by things that you might
- [Matt] want to redirect-- - [Brent] Yeah.
[Matt] that output to, a said, an alc, a --grep,
other unix commands that could
- [Matt] harvest it-- - [Brent] Yeah.
[Matt] out. But I love its cousin,
if you're only going to show it on the screen,
I love its cousin --color
- [Matt] -words -- - [Brent] Yes.
Just a neat little pair, a set of commands if you will.
[Brent] Right. So, and if you, You may actually notice this
on certain GitHub repositories,
as it shows you in the actual lines themselves [strikes key]
if there's only between two lines,
if there's two parts that really changed
it'll darken those specific parts using a similar fashion to this.
So, it's just pointing out this little bit has been removed,
it's red and this part has stayed,
this part has been removed, and this part has been added.
But, like you've pointed out, Matthew,
not as easily parsible
by some external system
like said or alc
that you might type these into, or save
- [Brent] these off of. So, all words,-- - [Matt] And I gave folks a sample
- [Brent] as well as-- - [Matt] But.
[Brent] word.
[Matt] You said
- [Matt] the darkening - [Brent] Well, yeah.
- [Matt] And just in-- - [Brent] perfect.
[Matt] the background I've got folks a sample
that they can click,
and they can see a number
and a token change in the light and the dark colors.
[Brent] Right, yeah.
I've often used that before I see
two lines that have--one will be red, one will be green,
but as I scroll throughout them,
it looks like they're the same
'til I get to that one point
when it's that one or two words that have changed,
or maybe its just an end symbol,
maybe its just a semicolon that I missed,
and it really brings that out
in the interface,
which I think is super useful.
So, with that, as a [strikes enter key hard ] great segueway,
I'm actually going to move over towards
actual collaboration now on to GitHub.
So, as we showed before, with that compare command here is--and this is a great way
to just get a good idea of different files that have comed in--come in, rather.
And here's those lines
I was actually talking about with the color,
things come in as green,
but what I wanted to focus on was more about issues,
issues and pull requests specifically.
So, when we have an issue we can think of them not necessarily as bad things,
but issues I think are more appropriately titled as a
They can be feature, they can be a bug.
Really it's not something to think of as issue as bad.
Issue to me means anything
that may not exist, or it doesn't work.
so, a feature or bug.
And, as you see with the interface here,
this is one of my favorite things
that has been added
in the past couple months,
whereas guidelines for contributing.
actually going to open this up on another tab
because, think this part is collaboration,
this deserves its own shoutout.
So, we can see with this file,
this is actually just a file that lives in
the root of this directory called, "contributing.nd."
doesn't actually need that nd
but for people coming to this page
with that mark down extension actually allows them to see it
in a way that it was possibly originally intended.
So contributing.nd gives a great heads up
to people who are willing to help out material or just a little bit of history
of the project itself maybe,
and I think that really helps people
to the table of, lowering
that fear that people may have of,
"Well there's this project I really want to work on it,
but I'm not really quite sure how to send my pull request.
Do they do rebasing? Do they do merge?
Do they do merge with no ff?"
As many teams as Tim and Matthew
can readily speak to,
many people have
- [Brent] many different-- - [Matt] Yeah.
[Brent] little differences in their
work flow that a contributing file will actually let people know exactly
what they need
when they come to a project.
[Matt] I would to see every project have this because it's really a,
"How do you be a good citizen here?"
It's either a guideline to the house
or its the guidelines of the city,
whatever you'd like to
- [Matt] [inaudible] write to-- - [Brent] Right! Yeah.
[Matt] How do you behave here, rather than bumping into walls
and offending people?
[Tim] [strikes key] That goal isn't for
a contributing file to filter or exclude so much as,
but to help people feel free.
Brent, you were saying a contributor
who doesn't contribute a lot might feel nervous.
And say, "I don't quite know quite the right way to do this."
So the goal of a good file is,
or good contributing guidelines is,
to help people understand and feel free
to contribute and have to worry about whether they're doing it wrong.
- [Tim] such as-- - [Brent] Absolutely.
[Tim] an opening
[Brent] Right. So, with that being said, there's just general issue sections here.
We can actually fill out
a simple issue, "include a thank you."
So, this is kind of a silly issue itself,
but we can see that with this
the issues actually has a list of people that can be assigned to it now.
This is my fork, so I am actually
the only collaborator on this project.
So, I'll go ahead and assign it to myself.
And, you can attach a milestone to this.
So, the way that would work is,
a number of commits that belong
to a milestone are--a number of issues, rather, that belong to a milestone--
as they're worked on,
will complete up to that milestone,
which kind of just feeds back to the whole idea that issues can really be
more of a project management tool,
or, whether that be for an entire project
or for an individual person.
I know personally in the past, I've worked on projects where I used the issues as
kind of a heads up to what I'm working on
that day versus that week,
and the importance of each of the features I'm working on.
You can do these with actually making new labels, adding to them now
with this specific example, "The readme doesn't include a thank you."
That's more of an enhancement,
so you can just add
that actual label right there,
and a little bit of text just saying,
"Hey"--
We can actually tag additional people.
Matthew, is your username on
- [Brent] GitHub, actually?-- - [Matt] [laughs] it is
- [Matt] It is, it is. You know - [Brent] Your full name?
[Matt] All of the continents.
Just take your fingers and roll them on
- [Matt] the keyboard-- - [Brent laughs]
[Matt] from the lefthand side, to the righthand side.
[Brent] So, if we actually do something
like this with an @ sign, Matt, you will actually recieve a notification
which would be denoted up here by an unread notification on his screen
that he was mentioned in an actual issue.
Now, you may have noticed
that it didn't auto populate his name.
That works in a similar fashion to the way these signees can actually work.
So, people who, maybe working within an actual project or the collaborators
on it would actually be prepopulated,
but this @reply format will actually still ping him on it.
So, sorry to fill
- [Matt laughs] - [Brent] your
[Brent] e-mail box a little bit there, Matthew, but
- [Matt] That's alright-- - [Brent] we can then
afterwards his username is highlighted. So, we can go ahead, and open that up,
see the beautiful Matthew.
And, he gets the e-mail notification,
and he's immediately brought
to the table on this contribution
or, for working on this project itself.
So, as we go and work
on this we can even leave comments,
as you would expect us.
There's many places within,
you can have interface where you can comment on issues.
But, if we were perhaps signed in as another user, we could see comments
as they come in and a full conversation would actually begin happening there.
So, also, you can actually look at-- this all is the linking that we had had
in Matthew's name.
To kind of tie back to this.
Matthew may notice that we go look at specific branches
Now, I've done some presampling
of commits on a previous branch called "collaboration-testing."
So, if you're following along,
I'm just using
this collaboration-testing branch from the GitHub interface
to see some specific commits that have come through.
So, actually work on this in the terminal.
[strikes key] So, we see here
that we're still on the gh-pages branch,
But if we go over to the collaboration--