Locally Switch to a Branch on GitHub

We're going to look at checking out a branch from GitHub.

In addition to starting with a branch on your local repository and then pushing it up to GitHub,
you could also work from the other direction, which is to create a branch on GitHub, then check
out that particular branch on your local system.
To start off, I'm going to create a new branch on GitHub.
I'm going to call this branch "update-readme".
Press enter to create that branch.
It's currently even with master, which is what we expect.
Let's go into the "README.md" file; let's make an edit to this file.
Once you're done with the edit, put in a commit message, I'm using the commit message
"Tweaked readme", then click on "Commit changes".
Great, now click on the name of the repository; we're back on the main page, and back on
“master”.
Let's say that I want to continue making changes to the "update-readme" branch, but I want to do
that on my local system.
Let's switch back over to our terminal, and I'm currently in the website Git repository on my
local system.
I'm on the “master” branch, and in a clean working directory.
Doing a "git branch -a" shows that I have “master” and a reference to 'origin/master'.
I know I just created a branch on GitHub, so I need to fetch those changes before I can continue.
Typing "git fetch" will update our remote, which would include any new branches that it might
be aware of.
And, at the end, you can see that we have a new branch "update-readme".
Now our references show an "update-readme" on origin.
There are several ways that I can link a local branch with the "update-readme" on GitHub, but
the simplest way is just to check it out.
Type "git checkout"; space; and then the name of the branch that you want to checkout, even
though this branch isn't local.
Now, this only works if you have a single remote repository; and the reason why this works, is
that Git will figure out what you mean by the name of the branch that you're specifying.
It's first going to look for a local branch named "update-readme", and when it fails to find it, it
will look for the name of that branch among the remotes.
As long as the branch name is unique among your remotes, it will find it and be able to check out
that branch; however, if you have a scenario where you have multiple remotes pointing to similar
repositories, where there are overlaps with the names of the branches, Git is not going to be able
to figure that out, and thus you'll need to take another approach to link a local branch with the
specific branch on your remote that you want to link.
However, in this case, Git was able to find the "update-readme" on GitHub, since we only have a
single remote named origin; and, in doing so, it made the assumption that I want to track the
branch, so that my local version of "update-readme" is tracking to the GitHub version of it.
It also automatically switched me to that new branch, which it is a new branch locally.
If I do a "git branch -a", you can see that I have a new local branch, "update-readme", and
technically, they are two different, distinct, branches, because I'm working with two different
repositories; a local repository and a remote repository.
Let's open up our Readme file; you can see that we have the edits that we made on GitHub.
Let's make some further edits; I'm just going to delete this line.
Great, so I've made some edits; going to save and close.
Back on the terminal, I'm going to commit those changes: "More tweaks to README".
Alright, so now we're ready to push up our changes.
And, since this is a tracking branch, we don't need to specify the remote reference or the branch;
we're going to assume the tracking relationship, wherever that happens to be pointing with our
current branch.
"git push", and Git figures out I mean push to the corresponding "update-readme" branch on
GitHub.
Let's check it out; if I refresh my browser, I'm going to switch to that branch I can see my
commit message that I've made on the local side, and if I click on "README.md", you can see
my changes that I made locally.

Cleaning Up By Deleting Branches and References

I'm going to make a few more tweaks to the "update-readme" branch, synchronize those back to
my local version, then synchronize all my changes to tracking branches locally, and then walk
through the process of merging locally then deleting the branch both locally and remotely from
the command line.
Alright, let's get started, I'm starting out in my "website" GitHub repository.
Let's switch to the "update-readme" branch; we just pushed up here, so we should have the latest
greatest version of it here.
I'm going to make a quick tweak to this file, and then commit my changes: "Commit changes".
Great, we have one more edit on our "update-readme" branch.
Now, let's switch back over to our terminal; I'm on my "website" Git repository on the local
system, and I'm still in the "update-readme" branch.
It's super easy to just do a "git pull" and get the latest greatest of the updates on GitHub, but I
want to show you another option.
Eventually, we're going to be merging with master, so I'm going to go ahead and check out to
there first.
Now, I'm on the master branch, and if I do a "git pull" here, without specifying anything else, I
will pull from master on GitHub, not from the other branch.
If I show you the configuration, "git config --global -e", at the bottom I have my push option
with the "default = simple".
And that simply means that whatever branch I'm currently on, only push and pull that particular
branch; however if I want to override that, I can use an option when I do a "pull".
If I do a "git pull --all", even though I'm currently on the master branch, Git will update all
tracking branches at the same time; so master to master and then my "update-readme" to
"update-readme".
Alright, let's integrate our changes "git merge" and then the branch name we want to merge in,
"update-readme".
Alright, we've integrated those changes, and it was such an easy merge we did a fast-forward,
which means we just assumed that we made the commits directly on master.
At least, from a history standpoint, that's what it's going to appear to be.
So now we have a few commits that are ahead of 'origin/master', so let's push up those changes.
Again, just do a "git push", and it's going to work with our current branch, which is master, so it
just pushed up our local master to remote master.
Great, now that we've integrated the changes, we no longer need the "update-readme" branch, so
let's delete it.
Ok, great, that branch has been deleted, and our local version of that branch is gone, but we still
have the remote; and, if we switch back over to GitHub, do a quick refresh, it's still listed up here
as a recent branch and, if I drop down, it's still listed here as well.
I could go into branches and delete it, but let's do it from the command line.
To delete a remote branch from the command line, type "git push"; and then the name of the
remote to use, which in our case is "origin", which references our GitHub repository; space; and
in the syntax we start the name of the branch with a colon, doing so is telling Git to delete
whatever the name is of the branch after the colon.
Alright let's do that. Great, when we did that, Git responded, saying that it deleted the "update-
readme" which is on GitHub.
Let's go check it out. It instantly updated the little notification we had about recent branches;
that's gone completely, and if I reload this page, do a quick dropdown, that other branch has been
removed.
And, we are down to a single branch, which, of course, is master.
Let's return to our terminal, and lets' check out all of our branch references.
Using the command line, like we just did, to remove our remote branch Git automatically
updated our references as well.
So, we don't need to do the "git fetch" with the prune option.

Pull with Rebase

We're going to explore the option of pulling with "rebase".
If you remember what rebase actually does, it rewinds the current commits that are on your
branch to a point to where the branch you're merging in originally diverged; then playing back
the commits that happened on the branch that you're wanting to bring in; and then, after that,
playing on top of that any commits that have happened on the branch that you're currently on,
thus making any changes that you have include the changes that happened on the remote branch,
but with your changes made ahead of them.
This is a good strategy when you're working on something, and you want to make sure that your
changes are ahead of whatever's going on from the remote side.
To start things off, I'm on my local system on the website Git repository; I'm on the master
branch, and at this point, everything is up-to-date.
If we do a "git pull", we can verify everything is up-to-date.
If I flip over to the GitHub side, do a quick reload, I'm currently on master, and I'm going to do
some edits on the Readme fie.
Click on the file, and then click on edit this file.
I'm going to delete these two lines, and then replace them with something else.
Once you've made the change, enter a commit message, I'm going to make my commit message
obvious, so it's easy to spot when we do our rebase.
Once I'm happy with that, click on "Commit changes".
Now that I've done that, I'm going to switch over to my local repository.
So, I'm back in my terminal, and before I pull in any changes from GitHub, I'm going to make
some changes on my local side first.
Let's tweak the "index.html" file, and let's just get rid of some of this conditional stuff that
supports older version of IE.
So I'm just going to delete that, and maybe even tweak the title. Once you're done with the edits,
save and then close.
Again, I'm going to make my commit message fairly obvious so we can tell what happened after
our rebase.
If we do a "git fetch" it's going to make this a little easier; you don't have to do the "git fetch",
but for illustrations it's going to help.
Basically, doing so will update our local Git with whatever changed on the remote side, so that
now, when I do a "git status", it tells me that the local branch master has diverged from
'origin/master'.
In this case, I could just merge in; I know, in doing so, it's going to create an automatic merge
which would result in a merge commit.
And that's ok, but what if I want to make sure that whatever I'm currently working on stays ahead
of whatever's currently in GitHub.
To do that, I can use a rebase; so type "git pull", and then use the option "--rebase" to cause a
rebase instead of a merge when it comes in.
As the message says, it's first rewinding the local branch, then it brings in our changes from
GitHub, and then it applies any commits that we had on the local branch.
So, let's check it out; I'm going to use my alias that I created before, "git hist" which is equivalent
to "git log" with a whole bunch of neat options.
So you can see, without history, that when it did the rebase it brought in the updates from
GitHub, it placed them before our changes we had locally.
So, you can see the commit starting with "1da8b22" is what 'origin/master' is currently pointing
to, which is our last commit from GitHub on 'origin/master' followed by the commit we just
made on our local copy on master, which is updating the index file before the rebase.
However, that commit did not include any of the updates from GitHub, so that's an interesting
distinction.
Before, when we had that on master, it only had the changes that we included while we were
here locally; it did not include anything that we changed on GitHub during this demo.
Let's check it out; let's make sure that the changes from GitHub made it down to our local
repository.
First, let's do a "git status". We are now just one commit ahead of 'origin/master', and that's just
the commit that includes the local changes that haven't been pushed back up to GitHub.
Let's check out the Readme file; we invoked our editor from the command line on our local
system, and it shows us the changes that we made to this file while on GitHub.
So, that means that we know that those changes made it to our local repository.
Alright, now that we're done, let's clean up by pushing up any changes we have back to GitHub:
"git push".
And since what we have locally already includes what was already on GitHub, all that's being
pushed are the changes that we've made locally.
Let's click on the name of the repository.
That brings us back to the main page and on the master branch; and, we see that we have
"Updating index.html locally before rebase".

GitHub Graphs
We're going to check out our network and branching graph on GitHub, and on the local system.
Let's start out on the local system.
Let's go back to our terminal, and I'm currently in the "website" Git repository, on the master
branch, and I'm currently in a clean working directory state.
Now that we've done lots of commits and some branching and merging, we should start to see
some level of branching off and merging back when we do our graph.
If I do a "git log --oneline --graph", the "--graph" option is what will denote the graph of our
branches as they come and go.
So, you can see some earlier commits were on other branches and they were eventually merged
back into master.
Some of the branches noted came from GitHub, and some were local.
I'm going to press 'q' to quit out of that, To give some more context, I'm going to use my "hist"
alias, which is equivalent to the "git log" command with several other options.
Doing that will actually show us the branches that are involved with each of the commits.
And, right now, everything is up-to-date at the top most commit.
So, both master and 'origin/master' are pointing to our latest commit.
And, we can scroll back into our commit history, and scroll back up as well.
Press 'q' to quit. We can see a similar type graph on the GitHub interface too.
Let's switch back over to GitHub.
I'm currently logged into GitHub, on the website GitHub repository.
Over on the right hand side, we have our repository menu.
One of the options is "Graphs", so click on "Graphs".
Within graphs, we have "Network", click on "Network".
Network will kind of give us a graphical representation of the different branches, and even other
people that have been forking off of our repository.
We'll cover that later, but for now, it just shows us our own branches and merging back in.

Setting the Default Branch

We're going to change the default branch of our GitHub repository.
I'm currently logged into GitHub, and I'm in the "website" GitHub repository.
I'm currently on the master branch, and at this point in time, it is the only branch we have;
however, in some work flows, the master branch represents what's currently in production, and
active development should not happen on the master branch directly.
Instead, there should be another branch that is also long-lived where all the development effort
goes, and then, periodically, those changes are merged back into master when the codebase
reaches production ready status.
So, let's set up our new develop long-live branch.
I'm going to expand out our branch dropdown, and in the search or create branch field, I'm going
to create a branch called develop, then press enter.
The branch named develop has been created, and is currently even with master.
That's OK; we don't need to make any commits for this demo.
Now, on the right hand side, we have our repository menu.
One of those options is settings, so click on settings.
These are the settings for this specific repository.
Under the main heading for settings, we have the repository name, which we have renamed
before, and we also have our default branch.
If we expand our dropdown, we have master, which is the current selection, and develop.
To change it, we just select develop. Now we can click on "Update" to set this.
GitHub will warn us since changing the default branch is not a trivial change; it does have some
consequences, in particular how new pull requests and clones react.
I'm going to click on "I understand, update the default branch."
Great, now develop is my new default branch, and I have a little banner at the top that confirms
this change.
I'm going to dismiss the banner. Now, let's get back to the main page for our repository, by
clicking on the name of the repository.
Right away, we see one effect of changing our default branch; when we click on the name of our
repository, we always land on our default branch, which now is develop.
Let's check out another side effect; expand the branch dropdown, and let's create a new feature
branch.
I'm going to create a throw away branch called "just-a-demo", and before I can issue a pull
request, I need to have at least one commit different from the originating branch.
So, I'm going to click on the faithful Readme file, and make a quick edit.
Once I've entered a commit message, click on "Commit changes".
Now, let's click on the name of the repository; that returns us to our main repository page, and
GitHub detects that we have a newly created branch.
In doing so, it offers us the option to compare and do a pull request.
Let's click on that button; the other side effect of changing the default branch is when we go to
create our pull request, our destination, or base branch, is now defaulted to the new default
branch, which is now develop.
For this example, I'm not going to go through with the pull request; this was just a quick example
to show this change in behavior.
Click on "website", now I'm going to delete the branch from the branches tab.
Find "just-a-demo" and click on the trash can. Great, now we've deleted that.
One last side effect I want to show, and that is what happens when you clone.
So, I'm going to scroll down, and below the repository menu are the clone options.
It's currently set to SSH, which is how I usually clone, and then click on the copy to clipboard
button.
That should copy the value that's currently in this field.
If you don't have it, then you can double-click on this field, select all the text within it, and then
copy the URL so that that URL will be in your clipboard.
Now, let's go to our terminal; back on our local system, I'm currently within the website Git
repository, but, for this example, I actually need to delete this repository and start over.
So, I'm going to back up one level, that takes us to our "projects" folder, under our user's home
directory.
I'm going to forcefully and recursively delete the website folder.
So, now we're left with a demo repository that we created earlier.
Now type "git clone" and then paste in the value that should be in your clipboard, which should
point to your GitHub repository. Once you've done that, press enter.
Great, let's go into the website repository, that's now been re-cloned onto our local system.
Now you see the other effect; that is the default branch that we get when we clone a repository
from GitHub will use the default branch set on GitHub.
So, now, it is set to develop; our local repository doesn't actually have a master branch, and the
develop branches are set up as tracking branches.
If I wanted to get the master branch on my local system, I would have to check that branch out
and fetch it down from the remote repository: "git checkout master".
Since there was no master branch on our local system, Git went out to our remote, origin, and
brought in the 'origin/master' branch and set that up as our local master branch.
So now, we have both master and develop on our local system; however, develop is still the
default branch on GitHub.

Dealing with a Conflict while Pulling

We're going to look at resolving conflicts between our local repository and our GitHub
repository.
Let's get started on the remote side.
I'm currently in GitHub, and I'm in the website GitHub repository; I'm on the newly set develop
branch as our new default branch, and while I'm here, I'm going to make a quick change that I
know is going to conflict.
Let's edit the "README.md" file; click on the file, and then click on edit this file.
At the end, I'm going to add some text, and then I'm going to go ahead and commit my changes;
again I'm making my commit message fairly obvious, so that we can track what's going on
"Problematic changes from GitHub".
Once I'm happy, click on "commit changes"; now, let's head over to our repository on our local
side.
So, I'm back in the terminal; I'm currently in the "website" Git repository.
Although I'm currently on master, let's switch over to develop.
Now that we're on develop, I know that we've made changes on the remote side, so let's do a "git
fetch" first.
So, if we do a "git status" now, we can see that 'origin/develop' is ahead of my local develop by
one commit.
I'm going to update my Readme file before I issue the "pull".
Now, obviously, this is a contrived example, but this would simulate what would happen if
you're working on a repository shared with others; they're moving forward, and if you don't keep
your repositories in sync you can run into changes that might conflict.
I'm going to paste in the changes that I copied from the GitHub repository side as a starting
place.
I made my changes, so now I'm going to save and close: "Updating README with malice on
local side".
So now if I do a "git status", the status tells me that develop has diverged by one commit on each
side respectively.
Let's try to do the "git pull"; normally what would happen if I was to do these type of changes
locally with local branches, I would result in a conflicting merge.
The same is true when we do a pull, since a "pull" is just a combination of a "git fetch" plus a
"git merge" targeting the remote branch.
And, as expected, this resulted in a merge conflict.
Like before, we can resolve our merge conflict by either modifying our files directly, or by using
a merge tool.
Since I have a merge tool configured, that's what I'm going to use.
"git mergetool"; that launches my merge tool, which, in this case, is P4Merge.
It provides me a nice, convenient, three way merge tool, which happens to be free.
I can inspect the different changes from the remote side and the local side, and then decide how I
want to resolve them, which could include a combination of both, or a complete re-editing of this
file.
I could come down here and decide I don't like any of these changes, so I want to do a
combination of both the remote and the local changes.
So, I'm going to copy this line, cut that out, and replace this text with just that one line.
Instead of just purpose, I want repository purpose, so I'm going to remove that.
Now that I've made my changes, I'm going to save. After saving, close P4Merge.
"Resolving conflict with unique approach", press enter.
If everything went well, you should exit the "MERGING" status, which merging just means
you're in a merge conflict, and you should be back to where we just have our branch name,
which means we're out of the "MERGING" status.
The only file we have laying around is our ".orig" file, which we can get rid of.
Now if we do a "git status", our branch is "ahead of 'origin/develop' by 2 commits".
So now, let's clean up by pushing. Let's go check it out on GitHub.
We're back on the Readme file, and we're still on develop, so just reload.
We now see our changes.

Local Tags (a bit of Review)

We're going to create a few tags in our local Git repository that we're going to be using with
GitHub during the next few videos.
I'm starting out fresh on my terminal program; I'm currently in my user's home directory, so now
let's go to the "website" Git repository.
That's currently in the "website" folder, within a projects folder, within our user's home
directory.
You can see that we are currently on the "develop" branch, and our working directory is clean.
Alright, so now let's get started.
I'm going to use the "git log" command, passing in "--oneline", to give me a summary of the
recent commits in our Git repository.
Using this list of commits, I want to create several tags that mark major milestones within this
repository so far.
If I type "git tag", I currently don't have any tags, and using the "git tag" without any parameters
will list tags if they are available in our repository.
The first tags I will be creating will be simple or lightweight tags, and I simply want those tags to
point to the HEAD position on the current branches for develop and master respectively.
To do that, I will create the first tag called "unstable", and I want it to reference the HEAD
position, which is the last commit on the develop branch.
So type "git tag"; space; "unstable", which is the name of the tag we're going to use; space; and
the reference point to associate the tag, which is "develop", which will mean the last commit on
the develop branch.
Now, if I do a "git tag", I see that I have a tag named "unstable".
Now, let's create another tag "git tag stable master"; in this case, we're going to create a tag
named stable on the master branch.
Type "git tag", and that will list both "stable" and "unstable".
To see our tags being listed type "git hist", which is an alias we created in a previous video.
You can see at the very top, we have the commit id "369b832", which has the tag "unstable"
associated with it.
You'll notice, within our history, that tags are noted with a "tag:", and then the tag name.
If we go a little bit further down, you can see that "a07fa0c" is associated with "tag: stable",
which is also on 'origin/master' and our local master branch.
Now I'm going to list out my commits using "git log --oneline".
The previous tags we created were simple or lightweight tags.
Simple and lightweight tags simply label a specific commit; there's no extra information
associated with those tags.
The next set of tags I want to create are going to be release tags, or annotated tags.
This time, I'm adding more information: "git tag -a", this is going to be an annotated tag; then the
name of the tag, in this case "v0.1-alpha -m" to provide a tag message; "Release 1.0 (Alpha)";
and then, at the very end, I'm providing the commit id that I want to associate with this tag,
which is "85fe102".
Double check the line and then press enter.
Now if I do a "git tag", I can see that I have the "v0.1-alpha" tag listed.
With annotated tags, we have the option of using the "git show" command specifying the tag:
"git show v0.1-alpha".
When we do that we see, at the very top, we have the tag followed by the tag name, and then the
tagger, the date, and the tag message; these are all specific attributes of an annotated tag.
After the tag specific information, we have the information regarding the commit itself,
including a diff.
Alright, let's list those commits again, and let's add a few more tags before we go to GitHub.
In this case, I'm creating a "v0.2-alpha" tag that is associated with commit "bb1e043".
Double check this line, and then press enter.
And this last annotated tag, we will name it "v0.3-beta", and associate it with commit "704f97c".
Of course, when you create these tags, you will want to use the specific commit ids that are
associate with your repository.
So, you will have different commit ids as you create these tags.
Let's list the tags by doing "git tag"; we have "stable" and "unstable", which are the lightweight
tags, and then our three tags that start with "v0." some number: two alphas and a beta, those three
of which are annotated tags.

Pushing Local Tags to GitHub

We're going to push up our tags to GitHub.
I'm currently in my terminal application on my local system, and I'm within the website Git
repository on the develop branch in a clean working directory.
In a previous video, we set up a couple of lightweight tags and three annotated tags on our local
Git repository.
If I flip over to GitHub, in this case I'm logged into my GitHub account and I'm on the
corresponding website GitHub repository.
I'm also on the develop branch, and there currently are no tags associated with this repository.
I can tell that, because if I go to the releases tab, I see there are zero and this icon shows tags.
In GitHub, releases and tags are nearly synonymous. If I click on "releases", it defaults to the
releases tab and I don't have any releases.
If I flip over to the "Tags" tab, it also tells me there are no tag here, but it calls them releases.
There is a minor distinction between the two, and we'll get into that later.
For now, let's return back to the terminal.
Before we work with our remote repository, let's make sure we've received all the updates from
GitHub before moving forward: "git pull".
Great, everything’s up-to-date, so now we can keep going.
Now, to send all our commits that we currently have on our local repository back up to GitHub,
type "git push".
Great, in this case, everything's up-to-date; that means that all the commits on our local side are
also reflected on the remote side.
What you'll notice is that, by default, tags are not sent to GitHub using the standard "git push"
command.
Since we just issued the "git push" command, we can go back over to GitHub, on the tags page,
and refresh.
We still don't have any tags here.
Return to your terminal, and now we need to use the "git push" command, specifying the tags we
want to push.
Type "git push origin", which is what points to GitHub; space; and then the tag name.
Once you press enter, GitHub will push the tag, and you'll know that because GitHub will
confirm with a response saying that it pushed a new tag, "stable", up to "stable".
Let's go see this on GitHub. Once on GitHub, and on the tags page, just refresh your browser.
Now we have a new tag named stable on GitHub, and we see the commit id that it is associated
with.
We also have a couple of options for downloading the source code associated with this Git
repository at this point in time; we have a zip file, and we have a tarball.
Now, let's return back to our terminal, and we just sent one tag to GitHub.
And, we could keep doing that with all our other tags; however, we have several tags and I really
want all of them up on GitHub.
To push up all tags to GitHub, I can specify the "--tags" option.
Type "git push --tags", now press enter.
Git will push the rest of our tags that we have in our local repository up to GitHub. Let's check it
out on GitHub.
Return to the tags page on GitHub, and then refresh your browser.
Now we see all five tags that are listed on the tags page.
On the tags page, you'll also notice that there's a "..." next to each of the tags.
For the lightweight tags, if you expand out the "...", the message here will be the commit
message associated with the commit id.
For annotated tags, when you expand out the "...", you'll have the specific tag message associated
with that tag.

Tags on GitHub
Great, now that we have our tags up on GitHub, let's get more familiar with the way that tags are
displayed on GitHub.
As I mentioned before, on this listing of tags, we have both annotated and lightweight tags listed.
For the lightweight tags, we just have the commit message associated with that tag.
And, for annotated tags, we have the corresponding tag message.
We also have the commit id that they're associated with, along with a zip file or tarball of the
source code from that version of our repository at that point in time.
We also have a reverse timeline, starting with the most recent and working our way backwards.
If you click on the tag name within GitHub, it takes you to a specific page about that tag; in this
case it shows that I tagged it 17 minutes ago, and that develop has had 14 commits since this tag.
It also shows me the message for the tag, and the downloads, which are the corresponding zip
and tarball.
If I click on "14 commits", it takes me to a diff comparing the tag that I clicked on and the
develop branch.
And, if I want, I can click on the specific commit id, which takes me to a page that has
information specifically about this commit.
And, on this commit page, you can see that we have our tag associated with this commit, as well
as being on the develop branch.
I'm going to click on tags to get back to our listing of tags.
Click on the name of the repository, and that will return us to the main page for this repository.
One thing I like to point out is that our branch dropdown, if we click it to expand, we now have
the option between branches and tags.
If I click on the tab for tags, I see a listing of all our tags that we have associated with this
GitHub repository.
I also have the option to find a tag if I had a really long list.
To see this repository as of a specific tag, just select a tag.
For example, I will select "v0.2-alpha".
Now, we are viewing this repository as of that particular tag.
At any point, I could switch to another tag, or to one of the branches.
I'm going to return back to that tag.
As I click around, I'm still viewing this repository as of this tag.
At any point, I could change the tag or the branch.

Deleting Tags on GitHub

Welcome, in this video, we're going to delete some tags both directly on GitHub, and on the
local system.
First, let's start out on GitHub; I'm currently logged in, and in the "website" GitHub repository.
Let's go over to the "releases" tab, then click on "Tags".
Let's say that we determine that we really weren't ready to push this tag up to GitHub.
So, I'm going to click on the "v0.1-alpha" tag, go into that page for that specific tag, and then I
have an option over here called delete.
Click on the delete button, and GitHub will warn me "Are you sure you want to delete this tag?"
Click on "Delete this tag".
Now we no longer have that tag listed; however, that tag still exists on our local side.
Let's go back over to our terminal, and we're currently in the website Git repository on our local
system, starting off on the develop branch in a clean working directory state.
If I do a "git tag", I can see that I have all my tags listed, including the "v0.1-alpha" tag, which
we deleted on GitHub.
If I do a "git fetch -p", that will fetch all the current references, just to make sure that I'm in sync
with GitHub.
Now, let's delete the "v0.1-alpha" tag on our local system.
Type "git tag -d" for delete, followed by the name of the tag, in our case, "v0.1-alpha", then press
enter.
Git will tell us that we deleted the tag. Great, now if we do a "git tag", it lists all the tags
available on our local system, and we should notice that we are missing the tag we just deleted.
Let's list the tags again, and this time I decide that the other alpha tag we don't need either.
This time, I'm going to start on the local side, and then move over to GitHub.
If I go over to GitHub, I currently have four tags, including the other alpha tag.
I could delete the tag on this side, but if I wanted a command line focused workflow, I could do
it all from the terminal.
First I'm going to start off by deleting the tag on the local side: "git tag -d", passing in the name
of the tag.
Once I've done that, I can also delete the tag on the remote side by pushing nothing to the tag
name.
Type "git push"; space; the name of the remote to use, which is "origin"; space, and then just
colon, immediately followed by the tag name to use; so, in our case, ":v0.2-alpha".
Double check the line and then press enter.
Git responds by saying the remote tag has been deleted.
Let's check it out, and refresh the page for our tags.
Now, none of the alpha tags are listed; we only have our beta tag.

Updating Tags Creating a Floating Tag

We're going to update our existing tags to point to a new commit, and then update GitHub to
reflect that.
I'm currently on the GitHub website, in the "website" GitHub repo.
I'm on the tags page, with three tags listed. One tag in particular that I wanted to draw your
attention to is the tag named unstable.
If I click on the unstable tag, it will take me to the page specific about that tag, and I can see, this
is the commit id that is currently associated with it, which at this point, is the latest commit on
the develop branch.
I'm going to update this tag by adding more commits to develop and then move this tag forward
to match the new commit id.
Let's head over to our terminal, I'm currently on my local system, in the website Git repository,
on the develop branch.
Doing a "git status" shows that I currently have a clean working directory, so let's get started. I'm
going to edit the Readme file.
Made a few changes to the Readme file; let's save and close.
Once you've made a commit, push those changes up to GitHub.
Let's see our new history by typing "git log --oneline --decorate".
And now, we have a new commit ahead of unstable; that's the commit that I added the commit
message "Updating readme with purpose section".
Below that, you see the commit that has the unstable tag associated.
Let's update our tag to point to the new commit id. In order to update an existing tag, you need to
use the "-f" option with the "git tag" command.
Type "git tag -f"; space; and then the name of the tag to modify; space; and then the optional
reference or the commit id to use with the tag, in this case "426900a".
I could just a easily leave that option off, and the tag would have assumed the head commit on
the current branch.
Double check the line and press enter.
Git responds with saying that it updated the tag 'unstable', and it told me which commit id it was
associated with prior to the update.
Now, if we do a "git log --oneline --decorate", we see that the tag unstable has moved up to the
latest commit.
Before we check out GitHub, let's push our commits that we have up to GitHub.
Type "git push"; do a quick "git pull", then "git push origin develop".
Double check GitHub, and we see that we have our latest commit, but if I click on releases
unstable still points to the old location.
We can see that by going to the unstable tag page, and it tells us that develop is ahead of us by
one commit.
Let's go back to our terminal, and let's try to push our tag.
Like before, if we type "git push origin unstable", we try to push our tag named unstable;
however, GitHub tells us that it already exists, and it rejects the push because of that.
There are a couple ways to fix that; one way is we could delete the unstable tag on GitHub, and
re-push, and basically replace the tag with the tag with a new location.
However, I'm just going to do this with a "force".
Type "git push --force origin"; space; and then our tag name, "unstable".
The "--force" will force the push of the newly updated tag to GitHub.
Double check, and press enter; Git pushes up that tag, and lets us know this was a forced update.
In general, you want to be careful with this, because you could cause a lot of people grief since
Git repositories are distributed.
So, there are only a few cases where you want to update tags that are already on GitHub.
Let's check it out back on GitHub; once on the GitHub repository, click on releases.
And now, unstable has our new commit id. If we click on the "unstable" tag, there's no message
saying that we're behind or ahead of develop.

Starting a Release on GitHub

We're going to talk about the differences between tags and releases, and then also create a new
release.
I'm currently logged into GitHub, and I'm on the "website" GitHub repository.
Click on the "releases" tab, and by default, it will land you on the "Releases" tab which, there's
also the option for tags.
Now, on first glance, there's not really much of a distinction; we have releases, and then we have
tags, and they both seem to have the same information.
The only difference is that releases is laid out just slightly differently, but it still just lists our tags
that we have available.
We have the option in the tags tab to add release notes, and release notes is where the distinction,
in my mind, comes into play.
So, let's pick on our "v0.3-beta" tag; next to it click on add release notes.
Adding release notes puts us back on the releases tab on a form that allows us to add release
notes to a particular tag in GitHub.
It will allow us to choose another tag if we want to, but I'm going to leave it on this tag.
I'm going to provide a title for my release notes, and then in the "Describe this release field", I'm
going to put the main body of my release notes.
Keep in mind it does support the markdown format, and you can see here, as I add my notes, that
I'm using the markdown syntax.
So, the two hashes mean a second level heading, the three hashes means a third level heading,
asterisks in front of a line will turn into bullets, and I'm able to reference specific issues and pull
requests.
For example "#2" references the pull request 2.
Before I create the release notes, I can preview what I'm doing.
Now scroll down, and since this is a pre-release version, I'm going to check the check box that
says "This is a pre-release".
If this was a production ready release, I would leave that unchecked.
When I get down to the bottom, if I decide that I'm not quite ready to publish this release, I can
save this as a draft, and come back to it later.
However, I'm good with the notes I've left, so let's click on "Publish release".
Great, so now I've created my release notes, and you can see that I have the title here at the top,
who created the release, how far back from develop it is, and then my release notes in Markdown
format.
So now, when we compare the difference between tags and releases, tags has this simple list of
tags.
Click on releases; while I still have references to various tags in the Git repository, we also have
the release notes being listed underneath releases.
If I needed to modify something, I could come over here and click on "Edit", and that will take
me back to the edit form for release notes.
Just added a note using double underscores for bolding.
When I'm happy with my revisions, click on "Update release", and now we see the modifications
that I just made.

Deleting a Release
We're going to look at the release page and also then delete our release. I'm currently logged into
GitHub, and on the website GitHub repository.
Specifically, I'm within Releases.
We just created a "Release 0.3 BETA".
If I click on the title, it takes me to a release page about this release specifically.
And, similar to the tags page, it lists the name of the release, the tag associated, the commit id
associated, whether or not this is a full release or pre-release, and other information about this
release.
I have the option to edit this release, which we've covered before, and I also have the option to
delete this release.
One thing to keep in mind is, if you delete a release it doesn't mean you delete the underlying tag
associated with it.
Let's try that out, click on the "Delete" button.
GitHub will warn you, "Are you sure you want to delete this release?"
Click on the "Delete this release" button.
Great, so now we're back, but we still have this listed under releases.
And that's because, by default, the releases tab will simply list out all the tags in GitHub, which
is not that much different than the tags tab.
In order to fully get rid of both the release notes and the tag, we still need to come in and then
click on the tag to go the tag page, and then click on "Delete" here as well.
Once you're happy, click on "Delete this tag".
Great, now refresh your page; now we're left with just two tags, stable and unstable.

Creating a Completely New Release

Welcome, in this video, we're going to create a new release and tag directly on GitHub.
I'm currently logged into GitHub and on the website GitHub repository within releases.
At this point, we have deleted all of our annotated tags and we are left with our two lightweight
tags: "stable" and "unstable".
If I go over to tags, I can see the same two tags listed.
What's interesting is, if I want to create a new tag on GitHub I can't directly do it from the tags
tab; instead it's folded in with releases.
Click on "Releases"; now, let's create a new tag and release at the same time.
Click on the button "Draft a new release".
This takes us to the release notes form, but we have some extra options now.
First we can actually create our tag name, in this case, I'm going to use "v1.0".
And, with a new tag name, I need to associate it some place in GitHub.
With the targets dropdown, expand it out; I have two branches I can use, or I can use a list of
commits.
I want my "v1.0" tag to be associated with the master branch.
Go back over to the branches tab, and then select "master".
Now, proceed to fill out the release notes like before.
I'm going to use "Release 1.0" as the header for this release.
Alright, so I'm going to use some markdown syntax, and I'm going to preview it before I submit;
so I have my heading and my bold for "master".
Once I'm content with this, I'm going to leave the "This is a pre-release" option unchecked, since
I want this to be a production ready type tag. Then click "Publish release".
GitHub will then create both the tag and the release notes under witch it's based on, and then it
takes us to the "Release 1.0" tag's page.
If we go back to releases, we can see that we have our other tags listed, and we also have
"Release 1.0" listed with the release notes.
And, this time, we have a nice green label that says "Latest release", which is different than the
other release we had, which was "pre-release".
If we switch over to tags, we have our "v1.0" tag.
Let's go back over to our local repository; I'm currently on the "develop" branch, within our
"website" Git repository on our local system.
And, since I know this tag is going to be associated with master, lets' go ahead and switch back
to master: "git checkout master".
If I list the tags that are currently available in our Git repository, we have "stable", "unstable",
and our "v0.3-beta".
Like I've demonstrated before, just because we delete the tag in GitHub, doesn't mean we've
deleted the tag locally.
In this case, I'd like to keep this tag locally for future reference.
In order to get all the updates from GitHub type "git pull".
Doing the "git pull", it sees our new tag out on GitHub and brings it down.
Now, if I type "git tag", it shows our "v1.0" tag.
Let's inspect our tag locally: "git show v1.0".
And I can tell by the output of the "show" command; since there's no tag specific information
when we show that tag, that means this is a lightweight tag, which means that GitHub will create
lightweight tags when you create them using the GitHub interface.

Comparing with Pull Requests

We're going to look at how we do comparisons in GitHub.
So far, we've done several commits on our GitHub repository, created a few branches and also
tags.
Since we've done all that we have the opportunity to do comparisons between commits,
branches, and tags in multiple locations throughout GitHub.
One way we could do that is by initiating a pull request.
If we click on pull request, it'll put us on a pull request page, by which I can create a new pull
request. Doing that puts me onto a compare changes page.
This will allow me to change the base, that is where I'm comparing against, with my current
branch or tag; let's compare "develop" against "master".
Doing that, we refresh the page with a difference between master and our develop branches.
So, at the top of this, I see that I have "4 commits here", you can see what dates they were on.
I can go to the specific commits by clicking on the commit message with each one or the commit
id associated.
And then, at the bottom of this page, I see a diff between the two branches being compared.
Right now, it's showing just one file changed between develop and master.
I have it on the unified diff, but I could also move over to split.
Doing that refreshes my page, and now I have a split view of the comparison.
At this point, I no longer need the pull request; I just wanted to use the pull request page to do
comparisons.
Let's click back on the name of our repository.
 Comparing Commits
We're going to look at comparing commits in GitHub.
There are several ways to compare commits; one way is just to go to the commits tab on your
current branch, and by default, when you go to a specific commit at the bottom of the commit
page, you actually have a diff comparing the current commit versus the prior commit.
And, in doing so, it provides a familiar interface that is common throughout GitHub for doing
compares or diffs.
And, on this specific commit page, we do have the option to add comments at the code level, or
at the overall commit level.
For example, I could come over here and add a message at this line, which comments in general
in GitHub will support Markdown syntax.
You can preview, and once you're happy with your comment click on "Comment".
If you want this comment to be associated with the entire commit, just leave a comment at the
bottom of the commit page.
You can preview once again; now, once you're happy, click on "Comment on this commit".
Great, now let's return to the main repository page, and click on comments.
On the comments page, we see that we have a comments icon that indicates that we have a
couple of comments associated with this specific commit.
Let's copy the SHA-1 associated with this commit; click on the "copy to clipboard" button, and
now let's use the pull request page to actually do our comparison.
Click on pull request, then click on new pull request.
In addition to comparing branches, you can compare branches to other references in GitHub,
including commits.
We'll leave the base to develop, and then we'll do the dropdown for the source location.
This dropdown allows us to specify a branch, tag, commit, or other history marker.
So now, I'm going to paste in the commit id that I just copied.
One you do that, select the commit id once it finds a match.
Sometimes, you don't see any differences, so let's switch branches to master; now we see some
differences.
When we do the compare with commits that have comments involved with them, we see that we
have commit comments associated with this particular comparison and we see the comments
listed below.
If we want to go a little deeper, we can; within the comparing changes interface, we have the
option to click on a specific commit.
Alright, let's return to our comparison.
And what you'll notice is, although we go to this page through the create a pull request
mechanism, if we are comparing against a specific commit or tag that doesn't qualify as
something we can pull request, the ability to do pull requests only happens when you're
comparing against branches.
And, we'll cover pull requests in more detail in upcoming videos.

Comparing Tags
We're going to quickly compare tags in GitHub.
I'm currently logged into GitHub, and on the "website" GitHub repository.
Let's click on releases, then go to tags.
We have three tags; we have "stable", "v1.0", and "unstable".
Let's remember those three tags.
Now, let's go to the far right hand side and click on the icon for pull requests, then click on "New
pull request".
When we land on the compare changes page by default it wants to compare branches together,
since this is the workflow by which we generally start our pull request mechanism; however, we
use this page for doing comparisons as well.
On the base, we're going to stick with master, and at this point, we are comparing master to
develop.
Let's expand out develop, and now we have an ability to specify a tag, commit, branch, or history
marker.
Let's use the tag "unstable".
Once GitHub finds a match, click on "unstable".
Now, we're comparing the unstable tag to the branch named master.
By the same token, we can change the base; expand it out, and instead of master, we're going to
type "1.0", then click on the item or press enter.
So now base has changed to 1.0, and we're comparing that against the unstable tag.
So, at this point, we are comparing two different tags.
 Advanced Comparing Even More Fun
We're going to do a little bit more advanced comparisons in GitHub.
I'm currently logged into GitHub, and I'm on the "website" GitHub repository.
Go over to the right hand side and click on "Pull requests", then click on new "pull request".
That will take us to the compare changes page, and by default, it's going to want you to compare
two branches together; however, if you scroll down, you'll notice that there's some advice on
other ways that you can do comparisons: branches, tags, commit ranges, and also time ranges.
For example, we could compare the head of develop against three days ago on develop.
Let's expand out our base dropdown, and then type an expression that will compare our develop
branch from three days ago: "develop"; and then the "@" symbol; then, in curly braces, a date
range "", then press enter.
This gives us a comparison, comparing the head of develop against develop from three days ago.
We can scroll down, and we can see the files that are associated with this comparison.
We can get even more specific; let's change this compare to a tag named "unstable".
Now we're comparing develop at three days ago to unstable.
Now let's change this to master at a specific date: "master"; the "@" symbol; then, in curly
braces, the specific date in the year-month-day format, "2015-28-05", that would be august 25th
of 2015, then press enter.
Now we're comparing master at that specific date against the unstable tag.
Again, we can look down and see all the changes that were made.
In addition to using date ranges, we can use commit ranges, including relative position to HEAD.
Let's change compare back to "develop", and let's change the base to "HEAD", which HEAD
typically points to the last commit on the current branch; then the "@" symbol; and then, in curly
brace, the number 3: "HEAD@".
Press enter, now we're comparing the current develop branch, that is the HEAD position at
develop branch, against the HEAD position at 3.
Let's do one more example; let's change our base to a tag, in this case we're using the "stable"
tag, against HEAD - 1 (HEAD^).
Press enter, and now we have our comparison from the stable tag versus HEAD - 1.
Scroll down, and you can see the differences involved.
 Copying A GitHub Repository by Forking
We're going to start off our social coding by forking an existing repository.
I'm currently logged into GitHub, and I'm on the "website" repository.
To show you where I'm going, I have another browser that's currently on the "starter-web" of the
"scm-ninja" organization in GitHub.
This is the repository that we are going to fork and make available on our personal space on
GitHub.
So, now I'm going to return to my main browser, and to set our bearings I'm going to click on my
username and that takes me to my newsfeed page.
And, I currently only have two repositories, which is my demo and my website.
Now, while logged in, I'm going to go to the "scm-ninja" username, so the URL would be
"github.com/scm-ninja", press enter.
Now find the starter-web repository; click on the name of the repository.
And now, at this point, we are not associated with this repository in any way, nor are we a part of
this organization; however, since this repository is a public repository, we can fork this
repository and make contributions, and later on submit pull requests to potentially have those
contributions accepted into this repository.
Let's start off by making a copy of this repository into our personal space by using the forking
mechanism.
Go over to the top right-hand side, and click on the fork button.
This will automatically make a copy of this repository into your personal space.
Once you land back on your personal space on GitHub, which you know by having your
username here at the top, and then you should have "starter-web", which is this repository, and
immediately underneath that you should have text that says "forked from", and the "scm-
ninja/starter-web" repository.
If we click on that link, that takes us back to the repository from which we forked.
From this point forward, I'm going to refer to this repository as my upstream repository or our
parent repository, since this is where we forked from.
I'm going to use my browser’s back button, and that will return me back to my copy of the
"starter-web" repository.
 Creating. Branch on Your Fork
We're going to clone our newly forked repository to our local system and then create a feature
branch, make some changes, which will then set us up for a pull request later on.
I'm currently in the "starter-web" repository, on my user's space, in my account in GitHub.
Let's scroll down and find the cloning options for this repository.
I'm going to leave it on SSH, and I'm going to click on the "Copy to clipboard" button.
That will copy this URL to my clipboard. So now, I'm going to go to my terminal, and I'm going
to make sure I'm in the "projects" folder.
Type "git clone"; space; and then paste in the URL that should be in your clipboard.
Review, and then press enter. Great, now we should have a "starter-web" folder within the
projects folder.
Go into "starter-web", and we should be on the master branch.
Let's create a feature branch on which to do our work: "git checkout -b" to create the branch;
space; and then the name of the branch, in this case I'm going to use "feature-readme"; press
enter.
We have created the feature branch and switched into it at the same time.
Let's do an "ls -l", and that will list all the files that are available in this repository; however,
there is something that is missing, and that is a Readme file.
So, let's create one: type "mate"; space; and then I like to use all caps for "README", then
".md" in lowercase: this signifies this is a Markdown format file.
I'm going to add some content to my Readme file, then save and then close.
Once you've returned to your terminal, we're going to add the Readme file to the Git index: "git
add README.md".
We currently have our new readme file in the Git staging area, so now let's commit: "git commit
-m "Adding README file".
Great, now we're back to a clean working directory on our feature branch.
Alright, now let's push this feature branch up to GitHub: "git push -u" to set up the tracking
relationship; "origin" which is the name of our remote repository; space; and then our branch
name, "feature-readme".
Double check the line, and then press enter.
If all went well, you should have a screen that looks like this.
In particular at the bottom we should see that we created a new branch, mapping "feature-
readme" to "feature-readme" on the remote side.
Let's go check it out on GitHub; back in my browser, I'm on the starter-web repository.
If I do a reload, you can see that GitHub has already detected a newly added branch: "feature-
readme".
And, in a minute, we will do the compare, but I also want to show you that the "feature-readme"
branch is also available in the dropdown of branches.

Pull Requests
We're going to check out our newly created feature branch and then submit a pull request to
contribute our changes to our upstream repository.
First, let's check out the newly created branch; if I click on "feature-readme" or select it from the
dropdown, I'm now on the "feature-readme" branch in my GitHub repository.
If I scroll down just a little bit, I can see that we have the "README.md" file.
The "README.md" file is a special file within GitHub; if GitHub detects it, it will display it at
the bottom of the repository listing.
Now that we've confirmed that those changes have made it up to GitHub on that feature branch,
let's proceed forward by submitting these contributions to our upstream fork repository.
To start that process, I can click on the "Compare & pull request" button, or within the listing of
the repository I can click on "pull request" when I'm on that corresponding branch.
I'm going to click on the "Compare & pull request" button to proceed.
By default, the pull request is going to set up the relationship back to the upstream repository.
This happens when your repository is part of a fork, which it is.
I have my main fork, which is my upstream or parent repository on "scm-ninja", and I have my
fork, which is in my user space on GitHub.
I want to make sure that I'm comparing my feature branch to the branch that I need to target in
my parent repository, in this case master.
Once I'm satisfied with this relationship, I can scroll down and click on "Create pull request".
Excellent, once you've landed on this page, you have successfully created a pull request.
And what you'll also notice is that you'll land on the target repository when this pull request is
created.
And that's an important distinction, because what a pull request is is the request from the
upstream repository to pull in your changes.

Updating Pull Requests

We're going to update our pull request.
I'm picking up from our last video, currently on the pull request targeting the "starter-web"
repository within "scm-ninja".
Let's take a quick look around the pull request page.
Currently, at the top we have the title of the pull request and the pull request number that's
associated with this repository.
In this case, pull request "#6" for the "starter-web" repository on "scm-ninja".
It tells me that this was opened by my user id, and that I want to merge one commit into "scm-
ninja:master".
In this case we're abbreviating by leaving out the name of the repository, from my user id,
feature branch.
If I wanted to, I could edit the title of this pull request, but I'm happy with it for now.
I also see that I have the conversation, which is the default tab, I have a commits tab, and I have
a files changed tab.
The commits tab shows me all the commits that were associated with this pull request, and the
files changed shows me all the files that are associated with this pull request.
Let's return back to the conversation. As you might imagine, the conversation tab has all the
comments that are associated with this pull request.
And, if there were multiple commenters on this pull request, you would see the entire
conversation listed on this tab.
This tab also gives me the general status of this pull request, and whether or not it can be merged
with the targeted base branch, which in this case it currently can.
On the right hand side, I have the ability to assign labels or specific milestones, or assign it to
another user within the repository for review.
One thing I'd like to point out is that I can keep adding more commits to this pull request, by
adding commits to the underlying feature branch involved with this pull request.
So, let's try it out; I'm going to go back to the terminal, and I am currently still on the "feature-
readme" branch on my local Git repository for "starter-web".
While I have a "README.md" file, there isn't much content in it, so I'd like to add a little bit
more content before we move forward with the pull request.
So now I'm going to edit the Readme file, and I'm going to add just a little bit more content to the
Readme file, then I'm going to save and then close.
And now I'm going to use the express commit, that is adding and then committing in one step to
establish my commit for my change: "Adding Purpose section to README", now press enter.
I now have a clean working directory, and I am one commit ahead of "origin/feature-readme".
Alright, so let's synchronize our changes by pushing up to GitHub; simply type "git push".
Great, in addition to those changes now being on the "starter-web" repository within my user's
space on GitHub, if I go back to the pull request page I now have my new commit associated
with this pull request.
This is the original commit, and this is my new commit.
Both commits are now associated with this pull request, and now I'm ready to accept the pull
request.

Accepting the Pull Request

We're going to review the pull request and then accept it.
I'm currently logged into GitHub, and on the "starter-web" repository.
In particular, I'm on the upstream version of that repository in "scm-ninja", and I have loaded the
page for the pull request that I just submitted, which is pull request "#6", "Adding README
file".
And, I'm viewing this pull request as my main user that I just submitted the pull request as.
In another browser, I'm logged in as another user on GitHub; in particular, a user that has read
and write access to this repository.
Write access is required in order to accept pull requests.
As that user, I'm going to go to my pull requests, that are part of my repository.
Once on the list of pull requests, I can go to the pull request that I'm interested in reviewing.
I'm going to select the top one, which is adding readme file.
On this page, I can see who submitted the pull request, what commits were involved, and the
files changed.
In this case, I see that we're adding a new file "README.md".
Let's go back to conversation; I can associate a comment with this pull request, using the
Markdown syntax if I wish to.
In addition to standard Markdown, GitHub supports a GitHub flavored version of Markdown
which has several extra features, including emoticons.
Any time you want to preview your comment, you can click on preview.
And, once you're done, click on "Comment", or if you wish to close the pull request at the same
time, "Close and comment".
Since I don't want to close this pull request, I'm going to click on "Comment".
Great, now if I scroll up, I can see the comment that this user then left for this pull request.
Also, if I flip over to files changed, I have the ability to leave comments at the source code level.
For example, I could go to line 5, click on the "+" mark, which expands out a comment field.
I leave a comment here; I'm going to preview it.
Since I'm happy I can leave the comment by clicking on "Comment'.
And now, that particular comment is inserted between lines 5 and 6.
And, since this part of the pull request operates much like other diff type sections of GitHub, we
can change our view from unified to split, which, in this case, doesn't make a lot of sense since
we just created a completely new file, but you can see that "README.md" has no content on
this side and all the content on the other side.
I also have the option to show or hide notes; if I uncheck, I no longer see my notes.
If I re-check it, then those notes re-appear. Returning back to conversation, I'm able to review the
merge status of this pull request, and GitHub will let me know if this branch can be automatically
merged or not.
Green check means it can; GitHub would let you know otherwise.
Once you're happy with the pull request, click on "Merge pull request".
I'm given the opportunity to modify what's going to be the commit message for this pull request
merge. For now, I'm going to leave it the same.
Once you're happy click on "Confirm merge".
Great, now we get a nice little merge icon, stating that this pull request has been merged into
"scm-ninja:master", and, while I'm still on this page, I have the opportunity to revert this pull
request if somehow I made a mistake.
If I return back to my main browser, I see that the status is already reflected on the main browser
that I have, logged in as my main user account.
And, I see that a different user accepted my pull request.
Directly from the pull request page, I have the option to delete the branch once the pull request
has been merged in successfully.
Since I don't need the branch once all the changes have been merged into master, I'm going to
delete the branch.
Great, now I see an indicator showing that I have deleted the branch.
And, while I'm on this page, I have the option to restore the branch, if for some reason I deleted
the branch by mistake.
Now I'm going to click on the "starter-web", and that will take me back to the main page of this
repository.
And, I'd like to show you after the pull request has been accepted, the pull request changes status
from open to closed, but, I can still access it by going to the pull request and then clicking on
closed.
That will show me all closed pull requests with "Adding README" at the top, at which point I
can revert my changes and even restore that branch, and I can see all the comments associated
with this pull request.
If I needed to, I can continue the conversation.
Alright, now that we're finished with our pull request example, I'm going to click on the octocat
icon, to return back to my newsfeed page for my logged in user.

GitHub Graphs
Welcome, in this video, we're going to look at the pulse and graphs section of GitHub.
Instead of showing those features with the main login that we've been using throughout the
course, I'm going to return to the "starter-web" under "scm-ninja", logged in with a different
account.
And, that's because that I have more data in this repository than I have with the repositories that
we've been using throughout this course.
So first let's check on "pulse", which is on the right hand side menu of our repository: click on
pulse.
The pulse will give us trends over time for our repository.
We can change the time period to show last 3 days, 24 hours, 1 week, or the past month.
And, this just gives us overall statistics about our repository, including merged pull requests;
proposed pull requests, which are pull requests that are open; closed and new issues, which we
will be covering in an upcoming section of this course; and then some general statistics about the
number authors involved, the number of commits, and how many additions and deletions were
involved across the board.
From here, we go over to the right hand side, and we see an abbreviated version of our menu; we
have icons that represent each of the parts of our repository that we can get to using that menu:
code; issues; pull requests; wiki; pulse, which we're currently on; and then graphs.
Click on "Graphs". The first tab we come to is contributors.
Contributors are all the people that make contributions to your repository.
I can filter by commits, deletions, and additions.
Next, let's click on traffic, and we can see the overall activity on our repository, including
number of clones that are happening; the number of visitors to the GitHub repository; our
referring sites; and our most popular content within the repository, along with the views and
visitors.
Next, let's check out commits. This shows us the commits that have been happening recently to
this repository. Now, let's check out code frequency.
This gives us a graph of additions and deletions to this repository.
At this point, we haven't been doing a whole lot, so there's not much to see here.
Now, let's check out "Punch card"; the punch card shows the commits we've made by day of
week and timeframe. Next, let's check out "Network".
Network shows a lot of the branches that are involved along with a lot of the forks as well.
Now, let's move onto "Members"; Members is a great way to see a list of all the people that have
forked your repository, including the fork that we created earlier, which goes to my
"jasongtaylor" user account.
I'm going to click on the name of this repository, and I'd like to show you there are sometimes
alternate ways to get to each of those items.
So, for example, I can click on the number of forks to take me to the network page.
 Synchronize Changes Back to Your Fork
We're going to synchronize our individual fork from our parent repository.
So far, what I've been referring to as the upstream or parent repository has been the repository on
"scm-ninja/starter-web".
And that's the repository from which we forked our copy of that repository, which is found in our
"jasongtaylor" account or would be found in your account if you've been following along.
We can see that by, on our newsfeed page, we have a section that it says repositories you
contribute to, and it lists "scm-ninja/starter-web", which gives us the option to go directly to that
repository, and if we wanted to, we could watch or star this repository.
Let's click star; this will send us notifications later if this repository changes for some reason.
Alright, so while we're here, let's copy this GitHub repository's URL; let's scroll down and find
the cloning options for this repository, that should be in the lower right hand side.
Change the default from HTTPS to SSH if you need to, then click on the copy to clipboard
button to copy the SSH URL to your clipboard.
Now, let's go back to our terminal. Back at the terminal, I'm in the "starter-web" repository on
my local system.
I'm currently on the feature branch we just created, in a clean working directory state.
Since I know we've merged in those changes into master in a different repository, we can change
out of this branch: "git checkout master".
Let's verify our changes on GitHub; so you'll notice that on "scm-ninja/starter-web" we have our
"README.md" file.
If I return to our version of that repository, we do not have that Readme file in the master branch.
So, how do we synchronize our upstream repository from which we forked down to our
individual copy of our repository?
Well, unfortunately there's no direct way to do that from the GitHub interface, so we must use
our local copy as an intermediate.
Let's go back to the terminal, and back on our master branch, let's go ahead and see a list of all
our remote repositories.
Type "git remote -v", "-v" is verbose, and that will show all of our remote repository references.
When we cloned this repository, we got origin set up for free; that is, when we used the "git
clone" command, Git automatically establishes a remote reference named origin back to where
we cloned from.
In this case, our "starter-web" repository on our user account on GitHub.
We do have the ability to add more remotes that refer to other Git repositories from which we
can push and pull.
To do that, we need to use the "git remote add" command; type "git remote add", then the name
of the remote reference we wish to create.
It can be anything we want, as long as it's something that we can remember.
Since I've been referring to the upstream or parent repository as upstream, I'm going to create the
remote reference as "upstream".
Now, paste in the URL that should be in your clipboard; command or control+v, then press enter.
Now when we do "git remote -v", it shows us we have two pairs of remote references: "origin"
and "upstream".
And, technically they're listed twice, because you can have different remotes for both the fetch
and the push; however, 99% of the time they should be identical.
Now I'm going to use the "git pull" command, specifying our "upstream" repository to fetch any
updates from that master branch.
Type "git pull"; space; and then our new reference, "upstream"; space; and then master for the
master branch; now press enter.
Great, now we've downloaded all the updates from the "upstream/master" repository, and in
doing so, we have our Readme file that has been added.
Now we have "README.md" file in our files that are part of the local repository, and since our
local repository has the changes that we just got from upstream, but our individual fork of the
repository on GitHub does not have that, we need to push our changes from our local repository
to our individual fork, which is currently referenced as origin; "git push origin master", now
press enter.
Great, now let's check it out on our personal fork.
Go back to our browser, and make sure that we're in our user account on the "starter-web"
repository.
Now let's refresh our browser, and if we scroll down, we should now have our "README.md"
file, and it should display at the bottom of our listing.
Super, now let's go back to our terminal, and do a little bit of cleanup.
Back on our local Git repository, if I do a "git branch -a" I show all our branches, including local
and remote branches.
I'm currently on master, which is exactly where I want to be, and it's time to delete that feature
branch.
Type "git branch -d feature-readme", and that will delete the feature branch.
Now, if you did not integrate the changes from the upstream repository onto the master branch,
then you wouldn't have the changes from the feature branch on master, and then Git would
complain when you tried to delete the feature branch.
But, since I've already integrated those changes, Git should allow me to delete the branch
without any problems. Super, the branch has been deleted.
Now, if I type "git branch -a", I see that I only have the master branch for my remote branches,
but something's curious here; I see that I have "remotes/origin/feature-readme".
That's a local references to our remote branch.
Let's check it out; I don't think we have that branch anymore.
If I go back, this is origin, so that's my user account on GitHub and the "starter-web" repository.
If I go to the branches dropdown, I only see master, which is further confirmed by the branches
tab showing only "1 branch".
If I click on it, I see that I only have master; so this repository definitely has only master.
But, on my local copy, it still shows that remote reference.
If you find yourself in this situation, you can fetch the latest updates passing in the prune option:
"git fetch -p", with the "-p" being the prune option.
Now press enter. Great, Git goes out to GitHub, notices that the "feature-readme" branch has
been deleted, which then it deletes the refine to that branch.

Enlisting Help with Collaborators

I'm going to introduce you to the concept of collaborators.
Starting off, I'm on the "jasongtaylor" user id that I have in my main browser, logged into
GitHub.
And, in a secondary browser, I'm logged in as "awesomejt" which is a different user that I'm
managing.
Logged in as "awesomejt", I want to add "jasongtaylor" as a contributor to one of my repositories
that I have within my user's space.
This feature is specifically for individual users in GitHub that want to allow different users to
contribute to a Git repository directly, that is grant read and write access to those repositories.
So, I'm going to go down to my repositories logged in as the "awesomejt" user, and select test,
which is just a public repo that I have as part of my "awesomejt" user.
Then I'm going to go down to the right hand side, of my repository, and I should have my
repository menu, with one of the items being settings.
Click on "Settings", and then on the left hand side is the list of settings options, one of which is
collaborators.
Click on "Collaborators", which then you will land on the collaborators page.
To add a collaborator, just search by their username, or their name, or their email address.
I happen to know the username is "jasongtaylor", which comes up in the search results.
Once you find a match, select that item, then click on add collaborator.
Now this user has read and write access to the "test" repository; this allows the " jasongtaylor "
account to directly edit this repository and accept pull requests into this repository.
Alright, let's check it out.
So, I'm going to head back over to the "jasongtaylor" profile; going to do a refresh to make sure
all my settings are updated, and now I see, under my repositories, the "awesomejt/test" repository
since I have write access to this repository.
So, I could go in and click on this repository and now I'm in the "awesomejt/test" repository.
While I'm here, I'll make a quick edit to the Readme file; click on the Readme file, click on edit
this file.
Once done editing the file, I'm going to commit my changes: then click commit changes.
Now that I've done that, I'm going to go back over to my other account, that is my "awesomejt"
user, reload the page, make sure I'm up to date.
And, on the collaborator's page, I may decide that I didn't want to add "jasongtaylor", or at this
point I may wish to revoke access.
I can revoke access by going to the collaborator's page, and then clicking the x to remove
"jasongtaylor" as a collaborator.
Once I do that, "jasongtaylor" is no longer listed as a collaborator, so now when I refresh, I only
have read access to this repository.
If I try to edit this file, it's going to recommend that I fork this repository first.
Also, if I click on the octocat icon, which will return me to the newsfeed page of my account, I
see that the "awesomejt/test" repo is no longer listed under my repositories.
 An Introduction to GitHub Issues
We're going to get started with GitHub issues.
I'm currently logged into GitHub, and the first thing I want to do is to make sure that issues is
available to my repository.
I'm going to do this with the website repository, so go down to your repositories and click on
website.
If you see issues over here on the right hand side, issues is available to this repository.
If for some reason this is missing, you can go into settings, and under features make sure that
issues is checked.
Great, let's return back to the main page for this repository, and click on issues.
Currently, there aren't any open issues with this repository.
At the top, we have various tabs that pertain to issues.
Whenever we create pull requests, an issue is created that tracks the pull request.
Labels are used with issues to denote the type of issue that you're dealing with, and then
milestones are just major events within the repository, AKA milestones.

Setting Up Issue Labels

We're going to be looking at labels within the GitHub issues feature.
I'm currently logged into GitHub, and I'm currently in the "website" repository.
And, within that repository, I'm within the issues feature.
Before I create an issue, I want to review the labels and perhaps even add some.
So, on the main issues page, click on labels.
Labels are a way of categorizing our issues.
By default, there are seven labels that come with issues: bug, duplicate, enhancement, help
wanted, invalid, question, and wontfix.
Most of these should be self-explanatory.
For example, bugs are intended for issues that are bug reports and enhancements would be new
features that we want to add to the particular project.
With each one of these, we have the option of editing or deleting the particular label.
So, let's do that; let's say, for our repository, "help wanted" really doesn't mean anything.
So, we're going to delete that particular label; click on delete to delete the label.
Once you click on that, GitHub will prompt you "Are you sure?" you want to delete the label.
Click on "Delete label" button to continue with the deletion, or if you want to keep it click on
cancel.
Since I'm not interested in that particular label, I'm going to click on "Delete label".
Now I'm down to six labels. Another option I have is to simply edit and existing label.
So, let's do that; find a label that you want to change and click on edit.
I'm going to edit the invalid label; click on "Edit".
The edit allows us to change two aspects: the name and the color associated.
Instead of "invalid" I wish to use "not applicable".
I'm also going to change the color to this light violet.
Once you've made the changes that you're happy with, click on "Save changes".
Finally, let's create a new label; go to the green button at the top that says "New label".
Click "New label", then that provides us an opportunity to provide a name and a color for our
new label.
I'm going to use the text critical to denote something more severe than bug, and I'm going to
choose the orange for the color.
Once I'm happy with this, click on create label.
Great, so this is my new list of labels.
Also, if you wanted to create more labels, the new label feature is still available, so you can
continue to add additional labels as you need to.
Once you're done creating all your labels, click on cancel.
Great, now that I'm done with the labels, I'm going to rerun back to my main issues page.

Setting Up Milestones
We're going to look at milestones within the GitHub issues feature.
I'm currently logged into GitHub, in my personal account, on the "website" repository.
Within that repository, I'm currently on the issues main page.
Before we create a new issue, let's look at milestones; click on the "Milestones" tab.
When you first get here, you won't have any milestones associated with this project, so let's
create one; click on the green "New milestone" button.
And milestones are just major events that you're building up to within your repository.
It could be a pending release, or some other type of checkpoint.
I'm going to create a milestone called "Beta 1"; in the title, I'm going to say "Beta 1".
In the description, I'm just going to type some descriptive text that provides a little bit more
context for this milestone.
Additionally, I could provide an optional date; I'm going to set this out to next week, then I'm
going to click "Create milestone".
Great, well I'm going to create another milestone while I'm here.
Click on "New milestone", I'm going to name this "Beta 2"; provide a description accordingly,
and set this two weeks out from where I currently am, and then I'm going to click "Create
milestone".
Great, now I have two milestones.
At any point I could delete a milestone, close the milestone, or edit the milestone.
For example, I'm going to edit Beta 2; go over to the right hand side, and click on "Edit".
I've decided that two weeks really isn't enough for the next beta, so I'm going to advance to the
next month and choose a more reasonable timeframe.
I'm going to select the 4th, then click "Save changes".
Great, I'm going to create one more for the purpose of closing it.
Go to new milestone; I'm going to create "Alpha 1", then, for the description, "This is the first
alpha for this project".
I'm going to set this date for a few weeks ago, then "Create milestone".
What you'll notice is that GitHub will let us know that we are past due by a month.
I'm going to go ahead and close this milestone; I can either do that within the edit page, or
directly on this page by clicking on "Close".
Closing the milestone will move that milestone from the open status to the closed status.
I can always access it again by clicking on the "Closed" status.
And, if I needed to, I could re-open this milestone, or I could just delete it.
I'm going to keep it around, and just return back to open.
Once you have a number of milestones listed, you also have the ability to sort, and we have
various options, including: closest due date, furthest due date, least complete, most complete,
most issues, least issues.
Since we don't have any issues yet, we're not going to bother sorting on those last two items.
Alright, I believe that's enough for now, so I'm going to return back to the main issues page.

Creating Issues
We're going to start creating issues in GitHub.
I'm currently logged into GitHub, and I'm on the "website" repository that we've been using.
I'm currently in the main issues page, which is accessible by going to "Issues".
In previous videos, we updated our labels to suit our needs for this particular project, and we
created some milestones, so now we're ready to create some issues.
Go back to issues, and on the issues main page, click on the green "New issue" button.
Once you're there, you have the ability to add a title, then write a comment related to this issue,
apply a label, milestone, and assign it to somebody.
Let's start off with the title.
The first issue I'm going to create is an enhancement: "Add getting started section to README".
In the comments, I'm going to add some Markdown, "README update", and then underneath
that, "Please add a _getting started_ section to the README, so folks know how to start with
this project".
If I flip over to preview, you'll see the markdown being applied.
Go back to write. So, I'm happy with my comment, now I'm going to head over to the right hand
side and look at labels.
I'm going to click on the sprocket, and that opens up the available labels to apply.
I'm going to select "enhancement", and while I'm here, I'm actually able to select multiple items
if I choose to. For now, enhancement is fine enough.
Once I'm happy, I'm going to use the x to close this dialogue; that updates the labels with
enhancement.
Under milestones, if I click on the sprocket the two open milestones are presented first, but I do
have access to the closed milestones as well.
I'm going to select "Beta 1"; that updates my assigned milestone.
And then, under assignee, since I'm the only one in this repository I'll just select myself.
If you had other team members helping you out, you would have a list of other team members
that are part of this repository.
Once you're happy with all the changes on this page, click on "Submit new issue".
Great, now we have created our first issue.
Once we create that issue, we actually land on the specific issue page.
You'll notice this starts with "#3", and that's because, on this repository, I created a couple pull
requests, which are also tracked as issues in GitHub.
So, my first true issue is "#3". On this page, we can see all the various aspects that are related to
a particular issue.
We see that I created the issue, and the markdown formatted message that I associated with this
issue, and the history of this issue.
And, on the right hand side, I see the label "enhancement" associated with this issue; and the
milestone "Beta 1"; and, of course, the assignee, which is myself.
If I scroll a little bit further down, at the bottom, I have the option of leaving additional
comments, and, of course, previewing that comment once I've written something here.
And then I can click on "Comment", or I can choose to close the issue.
For now, I'm going to return back to the main issues page.
On the main issues page, I have a listing of all my issues.
And, currently, I just have one, which is "#3".
From this page, I can click on the title of the issue to go to that specific issue page.

Closing Issues
I'm going to update my Readme file and then close the associated issue in GitHub.
I'm currently logged into GitHub, and I'm in the "website" repository that we've been using.
If I go to issues, I see that I have 1 issue. Click on "Issues". And we have an issue, that is an
enhancement, "Add Getting Started section To README".
Well, let's go work on that; I'm going to go back to my main page for the repository, and find my
Readme file. There it is, "README.md".
Click on the file, and for this simple example, I'm going to edit this file directly on GitHub.
Click on the "Edit this file" button, and after the purpose section, I'm going to create a "Getting
Started" section.
Alright, so let me preview my change; ok, that looks good.
Scroll down, and I'm going to commit my change: "Adding Getting Started section to
README", then click on "Commit changes" and now I'm going to return back to issues.
So now, I know I did the changes that are needed for this enhancement.
So I'm going to click on the issue, then write a comment describing what I did for this particular
issue: "Added **Getting Started** section in README file."
Let's preview it; good, "Getting Started" is bolded, which is great.
I could simply comment, but that would leave the issue open; let's instead click on "Close and
comment".
Even after the issue has been closed, you can still leave additional comments; however, for now,
I'm not going to do that.
Let's go back over to the right-hand menu, click on issues.
The default page for issues shows only open issues, which there are currently none; however, if I
click on the closed status, I see the enhancement that we just closed.
And, I can click on the title and go into that closed issue.
It denotes that it's been closed up here at the very top, and towards the bottom I see that the last
item in history is that I closed this issue.
All we have are the comments and the fact that I closed the issue, but you don't know which
commit was associated with it.
Now, I could go in and copy the commit, and reference it within my comments, but there is an
easier way, which I'll cover next.

Associating Issues with Commits

We're going to use commit messages to associate specific commits with issues; in particular,
we're going to close our issues using a particular syntax with GitHub.
First, let's go over to our issues page; click on "Issues".
Currently, there aren't any open issues yet, so I'm going to create one.
On the new issues page, title I'm going to use is "Exclude Mac OS temp files from repo".
In the comment, I'm going to say that "We need to **exclude** any temp files generated by the
Mac OS."
If I preview, I have "exclude" bolded.
Under labels, I'm going to click on the sprocket and assign this as a "bug".
For milestone, I can optionally pick one of the milestones; I'll select "Beta 1".
Assignee, I'll assign myself. Now that I've done that, I'm going to click on submit new issue.
Great, I created a GitHub issue that is labeled as a bug, and I also notice that this is "#4"; this will
become important here in a few minutes.
For this example, in order to address this issue, I'm going to hop over to the terminal, and I'm
going to fix this locally.
I'm currently in my user's home directory; and we go into the "website" project folder.
Since I'm currently on master, I need to switch to the develop branch.
I need to make sure that I'm working with the most up-to-date version of the develop branch;
type "git pull" to pull down any recent changes.
Great, so we just pulled down the Readme changes that we made earlier.
If I do an "ls -a", I see that I have my ".gitignore" file; that's the file that we want to edit.
I'm going to use my text editor, which is TextMate, to edit the ".gitignore".
I'm going to find a convenient location, provide a comment, "# Mac OS temp files".
In the next line, Mac OS uses ".DS_Store".
Once I've specified that pattern, I'm going to save and close; I'm going to add the changes we just
made to the staging area.
Now, let's commit the change, "git commit -m", then the commit message: "Ignore Mac OS temp
files," and then I'm going to use the specific syntax "close"; space; the hash mark or pound; and
the number of the issue we wish closed, which is "#4".
Once we do that, press enter. The commit that just got created is associated with the issue on
GitHub, but GitHub is unaware of that until we push up that commit.
If I type "git push", Git will push that recent commit up to GitHub.
Let's return to our browser, and this issue has already been updated.
If I scroll down, I see one of the items that I have is that I closed this issue from a commit.
In addition to that, I have the commit associated with this particular issue; which means that, if I
wanted to, I could click on the commit id, which shows all the changes that happened on this
commit id.
I'm going to go back; I see that I closed this particular issue from the commit.

Using Mentions with Issues

We're going to associate a previous commit with an existing issue.
In one of the previous videos, we updated our project, and then closed an issue; however, there's
no association between the work we did and the issue.
You just have to assume the work actually got done, or you have to do your own research.
Let's look and see; let's go to issues, then click on closed, because the issue I want to look at is
already closed.
The issue I want to look at is "#3": "Add Getting Started section to README".
There currently isn't any association between the work that was related to this issue, and a
particular commit that was involved with the work. So, let's solve that.
Let's click on "website", click on "commits", and we know the commit that has "Adding Getting
Started section to README" is the commit that's associated with that issue, so click on that
commit.
Then, let's scroll down; and the easiest way to associate this commit with that particular issue is
to simply mention it in a comment.
Now, if I type the pound or hash mark, I have a list of pull requests and issues that are available
to me.
I can continue by typing "3", or I can select issue "#3", then I finish my comment.
Once I'm happy with it, click on "Comment on this commit".
Great, now let's go check it out, click on "Issues", go to "Closed"; click on issue "#3", and let's
scroll down, and you see we have an association to that particular commit.
And, if we click on the commit id, we return to the commit that was associated with doing that
work for that issue, and we can even see what happened.
It's also important to note, if you have multiple commits involved, you don't have to use close to
close the issue.
You can simply reference the issue id without closing it, and it will associate any of those
commits with that particular issue.

Creating Gists
We're going to take a quick look at Gists.
I'm currently logged into GitHub, and I'm on my newsfeed page.
If you're somewhere else in GitHub, just click on the octocat icon at the top.
This will take you back to your newsfeed page.
At the top of the page, we have an item called "Gist" or "Gist", depending on how you prefer to
pronounce this.
Click on "Gist"; gists are a way of sharing little snippets of code, kind of like a Pastebin.
But it's not intended for a full file, although it can be; typically it's for one or a few files.
Using gists, it's basically a miniature Git repository.
Starting out, I don't have any gists, so I'm going to create one.
I'm going to give my gist a description; I'm going to call this: "Java Home Environment Variable
on Linux".
The file name I want to use, which would be the filename plus extension; I'm going to call this
".bashrc", and in the contents I will just type in or paste in the contents of the snippet of this file
that I wish to share with others.
I can add additional files if I need to.
For some systems, ".bashrc" file will be fine, but for others I will need to use another file:
".bash_profile".
So, this gist has two files, or really the partial of two files.
Once I'm happy with my changes, I have two options; I can create a secret gist or a public gist.
A secret gist is publically available, but excluded from search engines, so you must give out the
gist URL for people to access it.
If we create a public gist, the gist will be fully available to anyone searching on Google or other
search engines.
I'm going to create public gist.
Great, so I land on the page that is for this gist, and you can see it looks a lot like a miniature Git
repository.
For example, I can edit if I go up to the edit button; let's separate this out onto two lines.
Great, in bash I create a variable, in this case "JAVA_HOME", and set its value to
"/path/to/java", then I export the "JAVA_HOME" environment variable.
Then, I'm going to click on "Update public gist".
Great, so the code over here shows revisions; if I click on revisions, I can see a diff between the
different versions.
I'm going to click on the name of the gist to go back to its page, and at the bottom if I wish to, I
can leave a comment using the markdown format.
Once I'm happy with my comment, I'm going to preview it.
That looks good to me; click on "Comment" to leave the comment.

Working with Gists Locally

We're going to access our gist as a Git repository.
Starting off, I'm going to return back to GitHub; if you click on the octocat icon, you'll end up on
your newsfeed page, then we can click on "Gist".
This will list all of the gists that you have associated with your account.
I have one that is named ".bash_profile".
If I click on it, it will take me to that particular gist.
Just like the other Git repositories that we have, we have the option of cloning this as a Git
repository.
I'm going to go down to my clone options, and currently it's set to SSH, but HTTPS would work
as well; then, click on "Copy to clipboard" button. Once it's copied, let's return to our terminal.
Let's make sure that we're in the projects folder, so if you need to back up a directory do so.
From our projects directory within our user's home directory, I'm going to use the "git clone"
command: "git clone", then paste in the URL we just copied.
Normally I would let Git use the default directory name, but in this case I want to use something
more specific.
So type the folder name you wish to use for this particular clone, press enter.
If we do an "ls", you'll see the "my-gist" folder; let's go into that folder.
If we do an "ls -al", you'll see that we have both the ".bash_profile" and ".bashrc" files.
Let's make a quick edit; I'm going to add some comments to this file.
And, with bash files, comments are lines that begin with a hash.
Once you're done making your changes, save and close, and let's go ahead and add similar
comments to the ".bashrc" file.
Then save, then close; do a "git status".
I see that we have two modified files; so, although these files are associated with a gist, this all
operates like a traditional Git repository.
I'm going to add those files; both files show as modified.
I'm going to commit what's in stage, with the commit message "Adding comments to files".
Now, it's time to push: "git push origin master". If everything worked successfully, we should
have our changes back on our gist on GitHub.
Let's head over to our browser and refresh our page; great, now we see the comments that are
associated with this gist.
We also see the revisions went up to 3.
If we click on the revision, we have a comparison versus the last commit.

Sharing Gists
We're going to look at sharing our gist with other people.
I'm currently logged into GitHub; I'm on my user's account on the newsfeed page.
I'm going to click on "Gist" or "Gist" to go to the main gist page.
I have my ".bash_profile" gist from before.
If I click on "See all of your gists", I have it right here.
And I click on the name of the gist; once I do that, I'll land on the gist page.
This one actually has two files associated with it, and typically the way that we share this with
other people is simply to reference it by the URL; this URL is unique to this gist.
So, I'm going to copy it, and then include that link in emails, or forums, or anywhere else that I'm
posting, perhaps on my own website.
I could optionally use a URL shortener to make the URL a little shorter and/or provide a little bit
more user-friendly version of the URL.
For example, if I go to "bitly.com", I can paste in that URL, and then I would copy that, and
provide that in the forum or email, or any other communication with others.

Deleting Gists
We're going to look at deleting our gist.
I'm currently on the gist that's associated with my profile, and although it is a fine gist, I decide
perhaps I want to go in a different direction or I no longer want to make this gist available.
The option I have available is to delete the gist.
So, on the specific gist page, click the delete button.
GitHub will prompt me to ensure that I really want to delete this gist; I'm going to click "OK".
I get a blue banner that tells me I just successfully deleted the gist, and, in this case, I have no
other gist so I don't have anything to list.
Once I'm done here, I can click on view my profile on GitHub, and that returns me back to my
profile page on GitHub.
Once I'm here, I'm going to click on the octocat to return to my newsfeed.
Now, we're not completely done yet; we need to do a little bit of cleanup back on our local
system.
So, go back to our terminal, and I'm currently in the "my-gist" folder, which is the Git repository
for our gist, underneath the projects folder within our user's home directory.
Let's back up a level, and now delete the "my-gist" folder.
Type "rm"; space; and then us the "-rf" options; space; and then the name of the folder.
Double check that line, because the "rm -rf" command is extremely powerful.
Once you're confident that you have everything specified correctly, press enter.
Now if we type "ls -al", we no longer have the "my-gist" folder.

GitHub Organizations Overview

In this section, we cover an often overlooked and misunderstood feature of GitHub:
organizations.
People think that organizations are for companies, but that's not entirely true; I think of a GitHub
organization as simply a group of related repositories.
That means anyone can have an organization, or two, or even more; it just depends on how many
groups of repositories you have.
Sometimes organizations are related to a company, department, or a group of friends hacking on
a project together.
I actually have several GitHub organizations to group together several repositories from courses
I teach.
Also, it's fairly easy to transfer repositories from your individual account, or between
organizations.
In this section, we will cover setting up your own organization and all the management fun that
comes with it.
We will transfer one of the repositories we have been working with in our individual account,
and then forking that same repository back to our main account.
Along the way, we will explore the differences and similarities between individual accounts and
organizations.
A key part of organizations is teams.
Teams allow us to group contributors together in logical groups that have specific permissions,
depending on their role in our projects.
We will set up and manage teams within our organization.

Creating a GitHub Organization

We're going to create our first GitHub organization.
I'm currently logged into GitHub on my personal account, "jasongtaylor".
By default I land on my newsfeed page.
You can see that I have a list of repositories over here, as well as repositories that I contribute to.
If I go over to the dropdown for my user id, I see I have an option to switch to organizations that
might be listed here, which I currently don't have any, and I have the option of creating a new
organization.
Also, if I go over to the big plus mark, "Create new...", I also have the option to create a new
organization.
Starting off from either place is fine; since I'm here I'm going to click on "New organization".
Great, all organizations require that you have a personal account set up first, which we do.
On the create organization page, let's fill out the information for this form.
For organization, the organization name is equivalent to your username.
And when we type our organization name, GitHub is going to search to make sure it doesn't
match an existing username or organization name.
If I type a name that already exists, I'll be warned that the username or organization name is
already taken.
I'm going to create an organization called "my-organization-example" with dashes in-between
the words.
Once I completed typing it, GitHub verified that this username or organization name is available.
All organizations must have an email address associated with it.
Then, at the bottom, choose the appropriate plan; by default, you'll be on the "Open Source"
plan, which for our use will be perfectly fine since we'll be just creating public repos.
Once you have finished filling out the form, click on the green "create organization" button.
Great, now that you've done that, you've successfully created your organization.
By default, GitHub will land you on the invite organization members.
This assumes that you have other people that you wish to invite to this organization.
We'll cover this later, so for now we'll click finish.
Great, once we've finished up we land on the "my-organization-example" profile page.
To return to your newsfeed page, click on the octocat icon.
From the newsfeed page, we have the option now to dropdown and select our organization.
Doing so switches us to the organization's newsfeed page.
If we wanted to return to the organization's profile page we could click on "View my-
organization-example".

Transferring a Repository to the Organization

We're going to move an existing repository from my personal space into the new organization we
just created.
I'm currently logged into GitHub and, although I'm logged in as my individual user, I'm on the
"my-organization-example" profile page.
At the moment, we don't have any repositories, and while I could create a new one here, what I
want to do is actually transfer an existing repository into my organization and then fork it back to
my individual user.
To get stated, I'm going to return to the newsfeed page by clicking on the octocat icon.
Since I'm currently logged into the organization, I need to switch to my individual user account.
Once there, select the repository that we wish to transfer.
I'm going to pick on the repository named "website".
Right now, this website repository is associated with my user account.
In order to transfer this to somewhere else, I need to go down to settings, and on the main
settings page, I'm going to scroll all the way down until you find the "Danger Zone" area.
One of the items will be transfer ownership. Click on "Transfer".
Type the name of the repository that we're going to be transferring, and GitHub really does this
to ensure that we really mean to transfer the repository, since it has some downstream effects.
I'm going to type the name website, and then the new owners GitHub name or organization
name: "my-organization-example".
Now, click on the button that says "I understand, transfer this repository".
As a confirmation, GitHub will prompt you for your user's password; supply your password and
click "Confirm password".
Once you've done that, you should receive a banner message at the top saying that you have
successfully moved your repository to the organization that you provided.
In my case, it specifics "my-organization-example".
It also warns me this may take a few minutes, although in all actuality this shouldn't take too
terribly long.
We can x out of that notice, and then switch over to the "my-organization-example"
organization.
Back on the my organization's newsfeed page, we see that we now have the "website" repository
associated with this organization.

Forking Back to Your Account

Welcome, in this video, we're going to fork the organization's repository back to our individual
account.
Now that we've transferred the repository named website from my individual account into the
organization, I still want a personal copy of that particular repository to work on on my own and
then contribute changes back to the organization level at a later time.
To do that, I need to fork this repository; so click on the repository "website", Going into here,
we see that we are clearly in the "my-organization-example" version of this repository; and to be
clear, if I go back to my account the repository "website" is associated with "my-organization-
example" and not my personal account.
To create a copy that's on my personal account, I'm going to click on the "Fork" button and since
I have both my private account and an organization, I'm given the opportunity to choose where to
fork the repository.
The option for the current location is, of course, greyed out since we're already there, so I'm
going to choose my personal account, which is "@jasongtaylor".
Great, now I have successfully forked that repository, which has taken me to the "jasongtaylor"
version of that repository, and I see that I have, underneath that, it tells me that I am forked from
the my organization version of that repository.
This is the general workflow that I like to do when I'm working with organizations; is that I will
transfer any repositories that were at my personal level, to the organization, and then I will fork
them back to my personal account on GitHub; you cannot set up the relationship after the fact.

Updating Remote Referneces on the Local side

We're going to return to the local side of our Git repository that corresponds to our GitHub
repository.
In previous videos, we transferred the "website" repository from our personal account to the
organization account, and then we forked it back again.
So now we end up with the copy of the repository in both the personal level and the organization
level.
This is a common setup when you're working with GitHub in something known as the "pull
request workflow"; so, we are slowly building up to that eventual workflow.
The next step is to make sure that our remote references are set up to point to the individual
account, as well as the organizational account GitHub repositories.
Let's return to the local side; I'm currently in my user's home directory.
If I change directory into "projects/website", I land in the main folder for the website Git
repository on the local system.
Right now, we are on the develop branch, and we currently have a clean working directory.
As I've shown before, we have a remote reference named "origin", that currently points to the
"jasongtaylor" version of our repository on GitHub.
And, since we forked back from the organization and ended up with a copy of the website
repository within the "jasongtalyor" user account, nothing needed to change for our remote
reference named "origin".
And, in fact, we will keep it named origin and add the other reference back to our organization as
another remote reference.
To do that, I'm going to return to my browser and click on the "forked from my-organization-
example/website"; that will take me to the organization's version of the website repository.
One thing to keep clear is that this repository and where I came from are two separate
repositories.
In all actuality, we're dealing with three separate repositories; one at the organization level,
second one at the individual level, and the third one on our local system.
These are all three separate distinct Git repositories, although they are named the same thing and
may have similar histories.
Alright, now that I'm on the organization version of this repository, I'm going to go to the lower
right hand side and look for my cloning options.
I'm going to make sure that I'm on SSH, and then I'm going to click on the copy to clipboard
button.
Once that's copied, I'm going to return back to my local system.
Since we already have a remote reference named "origin", we need to name this reference
something else.
And, to do that, I'm going to use Git's "remote add" command.
Start off with "git remote add"; followed by the first parameter, which is the name of the remote
reference we wish to create, I'm going to call this "upstream"; then provide a space; and then
paste in the value that should be in your clipboard.
Make sure this references the organization's version of the repository, and not the one that's on
your personal account. Once we've done that press enter.
Like many commands in Git, no news is good news, so let's verify with the "git remote -v" again.
Great, now we have both origin and upstream specified, and they point to the website repository
on the personal account and the organization account respectively.
We can try it out by using out "git fetch" command: "git fetch upstream".
Doing so, Git will reach out to the remote named "upstream", which points to our organization
version of our repository, and, when that happens, Git will notice two new branches, master and
develop, that are associated with the upstream remote reference.
If you want to fetch from all the remote references at one time, you can use the "--all" parameter
that's part of "git fetch".
Let's try that now: "git fetch --all".
Git will go to "origin" and then "upstream" to fetch any new references.

Branches and Confusion

I would like to point out one particular nuance when working with multiple remotes, and that is
how to specify a branch that exists in both remote locations.
To show this, I'm going to return to my browser; I'm currently logged in and on the organizations
version of the website repository.
I'm going to create a new branch called "shared". I'm going to base it off of develop, by just
typing the word shared in the search field for our branches; press enter.
Great, now we have a new branch called shared in the organization's version of the "website"
repository.
Now I'm going to go down to my individual version of this repository.
One way I could do that is clicking on the number of forks, then click on members.
I see that one of my forks is my personal account, so I'm going to click on the "website" under
my personal account.
Once I've arrived there, I'm going to do the same thing: type "shared".
This should create a branch called "shared" under develop.
Now, at this point, both repositories have a branch named "shared".
Now, let's return to the local version of the Git repository.
Back on my local system, I'm with in the "website" Git repository on the "develop" branch in a
clean working directory state.
If I do a "git branch -a", it shows me all the local branches and remote branches it's currently
aware of.
And I say currently aware of, because we haven't fetched any new references that exist on the
remote repositories, so the remote references are not currently updated to reflect the newly
created branches on both repositories.
To do that, we can type "git fetch --all".
Doing so, Git will see that we have a new branch called shared in each of our remote references:
"origin/shared" and "upstream/shared".
At this point though, one thing to note is that our local repository does not have a shared branch.
Well, let's try to "checkout" shared: "git checkout shared".
In this case, however, we get an error back from Git, saying that it could not match any files
known to Git.
Now, if you don't know what's going on, you might be a little confused by this error message.
Git basically has an order of precedence, which it tries to checkout whatever you type in to the
checkout command, in some cases, that's actual the name of a file.
That's when it doesn't match a particular branch or tag name.
And, you might be wondering, well we have shared in both "origin" and "upstream", so it could
have matched one of those; but, Git doesn’t work that way.
If we only had origin, then Git would have been smart enough to detect that we really meant
origin shared, and would have made the connection, checked out that branch, and associated a
tracking branch between "origin/shared' and a newly created branch called "shared".
We have to use the "git checkout" command, just slightly differently to associate "origin/shared"
with a new branch.
Type "git checkout -b", which is to create a new branch since this will be a new branch on the
local repository; space; and then the name of the branch, which we'll just call it "shared"; space;
and then our starting point, which our starting point will be "origin/shared".
Once you've done that, press enter; Git responds that branch "shared" is set up to track remote
branch shared from origin, which is exactly what we wanted, and we switched to the "shared'
branch.
Since this is a tracking branch, we can simply type "git pull" and it goes out to GitHub to make
sure that we're up-to-date.

Organizations vs Personal Account

I want to compare the differences and the similarities between individual accounts and
organizations.
First of all, I'm currently logged into GitHub, and if I click on the octocat icon, I will return to
the newsfeed page.
I'm currently on my user account's newsfeed page, and if you're somewhere else, you can click
on your user id to make sure that your newsfeed page shows up.
One similarity that individual accounts and organizations have is the concept of a newsfeed page,
which shows you recent activity, and gives you high level access to the repositories that are part
of the individual account or the organization's account.
Organizations also have a listing of repositories that they manage.
If I switch back over to my personal account, I also have my repositories, and the only difference
here is that I have access to repositories that I have read and write access to, which includes the
one that's underneath the organization that we just created.
I can go to a profile page that gives me high level statistics about my individual user.
On a similar note, if I return to my newsfeed page and then select my organization under the
dropdown, I can view the organization's profile page by clicking on view, the organization name.
This is the same concept, although it has different information.
If I click on "View profile", under my user account I have settings.
Underneath settings, I do have an option for organizations.
This allows us to manage our relationship to organizations we've created, or that we're otherwise
a part of.
Also, underneath personal settings, you have a link to organization settings.
This organization settings will list all organizations that you're currently a part of, and will take
you to that organization's settings page.
Doing so, we can see the settings and organizational profile for this particular organization.
Alright, at this point, we can click on the name of the organization, and that returns us back to
the public organization's profile page.
So, you can see that the organization and the individual user share many things in common, but
they also have distinct differences.

Working with Teams

We're going to look at setting up teams and adding team members to those teams.
I want to start off by showing you that I have two browsers set up so that I can show two
different user accounts in GitHub.
On one browser I have set up my "awesomejt" user in GitHub, and in another browser I have the
"jasongtaylor" account.
Also, the "jasongtaylor" account is currently the owner of the "my-organization-example"
organization.
I just mentioned something called owner, and that comes into teams.
So on the my organization page, I'm going to switch to the organization's profile.
Once there, I'm going to click on "People". People shows all members of the organization, and
right now, my "jasongtaylor" account is the only member of the organization.
Right now, it shows that my membership is private; that means that only members of this
organization will know that I'm part of this organization.
If I want other people to know that I'm part of this organization, I need to select public.
Whether you're public or private doesn't matter, and it doesn't influence whether or not you pay
for GitHub or not; this just effects the visibility of your membership in the organization.
If I click on "Owner", I see that I have full administrative access to the entire organization; the
owner role is a special role that is like super admin for this particular organization.
All organizations must have at least one owner.
Great, now I want to invite another person to join the team; however, before that, I want to create
another group called a team, so I'm going to go back to the "Teams" tab.
I'm going to scroll down, and find the green "Create a new team" button.
Let's name the team "Developers". GitHub is going to do a search to make sure the name of the
team is unique within the organization.
In the description, I can provide an optional description of this team.
In this case, developers will have read and write access to repos.
And then I'm going to make this team "Visible". I could make it a secret, but I prefer to leave it
as visible, so the "@mentioned" will work.
Click on "Create team". By default, the user that creates the team is automatically part of that
team, so you can see that I'm part of the developers team.
Let's add another person; I'm going to click on "awesomejt" after typing in "awesomejt".
GitHub will automatically search for any users matching the search criteria.
Once the match is found, just click on the item that you wish to select.
Anyone that is not already part of this organization, will be sent an invitation.
And, if I wanted to, I could edit this invitation.
On the invitation page, I can select for the invited user to be just a member of the organization or
an owner of the organization.
You can definitely have multiple owners of the organization, just keep in mind that owners have
full administrative access to the entire organization.
I'm going to leave it as "Member".
Also, I can select all the teams that I wish this user to be part of once they accept the invitation.
And, of course, I have the option to cancel the invitation or, if I made changes, to update the
invitation.
I'm going to go back by just clicking on people.
Now I'm going to hop back over to the other browser, which as the "awesomejt" user account.
Let's reload the page; we just want to make sure we have the most up-to-date information.
I know that I have a pending invitation to the "my-organization-example" organization.
Depending on your settings, you may receive an email with an invitation that will take you to
that particular organization.
Otherwise, you can go directly to the organization's profile page.
So, back on the other browser, I'm going to copy the URL to the organization's profile page and
then return to the other browser logged in as "awesomejt".
And, in the address bar, I'm going to paste in the URL to the organization that I just got invited
to.
Once I land on that organization's page, I should have an invitation at the top saying that
"jasongtaylor invited you to join the my-organization-example organization", and this happened
"6 minutes ago".
Now I'm going to click on "View invitation".
On the invite page, I have the option to join that organization, so click on the green join button.
Great, now I am a member of the "my-organization-example" organization.
Now, I'm going to hop back over to the other browser and refresh, and now I see the
"awesomejt" that's part of the people of this organization.
Click on "People"; I now have "awesomejt" and "jasongtaylor".
By default, this member joined with the private visibility, and as we set up "awesomejt" is a
member of the organization, not an owner.
And, if we go to teams, developers now has two members; our team members are "awesomejt"
and "jasongtaylor".

Team Permissions
We're going to further manage our teams.
I'm currently logged in as "jasongtaylor", but I'm on the "my-organization-example"
organization.
If I go to people, I see I currently have two people that are part of this organization: "awesomejt"
and "jasongtaylor". If I hop over to "Teams", I currently have one team called developers.
If I click on "Developers" I go to the developers team page, which allows me to manage the
settings, and who's part of this team, and any repositories that are associated with this team.
If I click on settings, I have the ability to edit the team.
I'm going to change the description to "Team for development staff".
Once I've done that, I can click on "Update".
Great, the description for the "Developers" team has changed.
Another aspect of the teams are the repositories that are associated with the teams.
Teams have two facets; the team members, and the repositories.
Let's click on "Repositories"; by default, there are no repositories associated with this team.
If we go to "Add repositories", and just start typing the name of a repository name, we should
have a listing that includes something that matches our search criteria.
Once we find the repository we wish to add to this team, we just click on it and it is added to this
team.
I also have the option to choose the visibility of this repository within this team.
By default, it's going to place it as read-only, which only allows members part of this team to
have read or view access to this repository.
If I want to, I can use the dropdown, and change the permission level.
"Read" means it allows team members to read or view the contents of the repository and to also
clone the repository, or even make a fork of this repository into their personal space on GitHub.
This is a fairly common level when working with open-source projects that you're not directly
managing.
"Write", which is the next level up, allows team members to read, clone, and push to this
repository.
It also allows developers to directly make modifications to files on the GitHub repository, and
then finally "Admin" allows team members to have admin access to the repository, which means,
in addition to reading, writing, and pushing, it allows team members to add other collaborators to
this repository.
For the development team, I want all repositories that are associated to have write access.
Once I select "Write" GitHub automatically updates that permission.
Great, I'm going to click on the name of my organization, and that will just take me back to the
organization's profile page.

Managing Teams
We're going to move the "awesomejt" user from the developers team into a new team.
I'm currently logged into GitHub, and I'm on the "my-organization-example" organization.
If I click on teams, I currently have a single team called developers.
I'm going to create a new team and call this team "Contributors"; and the description I'm going to
use is "Read-only team for less trusted developers".
Then click, create team. While I'm here, I'm going to associate a repository, so click on
"Repositories".
Type "web", which should bring up the website repository, click on that, and I wish to leave
"Read" as the permission for this repository.
Again, read allows team members to view or read this repository, clone it, and also fork the
repository.
Alright, let's head back over to team members.
I'm going to add the "awesomejt" user.
And, at this point, I just have to type the first few letters of the username, and since this user's
already part of this organization this match will show before anyone else on the general GitHub
website.
Once I find my match, I'm going to select it, and this time, since the "awesomejt" user is already
a member of this organization, the "awesomejt" user is directly added to the contributors team;
no invitation is required at this point.
Great, so now let's head back over to teams, and "awesomejt", at this point, is a member of both
contributors and developers.
Let's go over to developers; I need to remove "awesomejt" from developers, so that he only
remains in the "Contributors" team.
So, I'm going to go over to the gear dropdown, and then select "Remove from team".
GitHub will update and remove "awesomejt" from this team.
If I click on teams, I can see that "awesomejt" is still part of the contributors team.
I like setting up my organizations in a fashion like this, where I will have a core team of
developers, and then a team of contributors with different permissions.
Typically my trusted core developers I will give more permissions, in this case read and write,
and then contributors I will give less permissions, in this case only read access.

Organizations Profile
We're going to look at updating the organization's profile.
I'm currently logged into GitHub as the "jasongtaylor" user, and I'm on the "my-organization-
example" organization’s profile.
As the organization's owner, you have access organization’s profile, and can update its settings.
From the profile page click on "Settings".
Like an individual user, the profile has many of the same types of settings that you would
normally associate with an Indi dual, including a profile picture, name, email, and other
information.
Let's update the profile picture.
Click on "Upload new picture".
I'm going to use a wave png that I just downloaded off the internet.
Click open; I'm given the opportunity to crop the picture, then, once you're happy with the crop,
click "Set new profile picture".
Once that's done, we can continue down the rest of the profile page.
I'm going to use "The Example Organization" for its name, "example@git.training" for the email
address.
For the description, I'm going to use "This is an example organization for GitHub training".
I'm going to use the URL "http://git.training".
And, since I'm located in Florida, I'll set its location as Florida.
And the billing address, which is kept private, can be your own email address that isn't
associated, per se, with the email address for the organization, which is public.
Once you're done updating the profile, click "Update profile".
Great, now the profile has been updated.
Let's do a quick review of the rest of the items in the menu for the profile settings.
Click on "Member privileges"; this allows us to allow members to create repositories in this
organization: by default they can.
The default repository permission, that is when you invite new members to the organization are
given the read permission by default.
You can also update to "Admin", "Write", or "None".
None would only allow members to clone or pull public repositories.
And really, for public repositories, "None" and "Read" have similar effects.
The difference is, is that if you happen to have private repositories, which again would require a
paid membership to GitHub, the read permission would allow read visibility to any private repos
as well as public.
For now, I like keeping it at read.
Team privacy, this allows us to make global changes between making all of our teams visible or
not.
Billing allows us to update our billing information, if we were in the mood to change to a paid
account.
For now, I'm happy with keeping it as free.
Applications allow access through GitHub API; third-party access is a little bit more advanced.
Audit log will show all the events that have happened in the organization.
The audit log also allows us to export, which is available in "CSV" or "JSON" formats.
We can see here all the activity that has taken place since we created the organization.
And then, finally, Webhooks is an advanced topic that relates to how repositories communicate
with outside tools.
Click on the name of the organization to go back to the profile page.
So, as you can see, things have changed a bit since we updated our profile.
So now, instead of "my-organization-example", which is still up here in the URL, the name of
the organization is "The Example Organization", which also has the description, our location in
Florida, the URL, and the public email address.

Destructive Actions
Before we wrap up this section on working with the organization in GitHub, I wanted to go over
some of the more destructive aspects of managing your organization.
First, let's look at people. When we look at our people, we have the option of kicking people out;
so I can select a user and then change the role.
I can convert to an outside contributor, which means this person's no longer a part of the
organization, but is allowed to make contributions, or I can remove from this organization.
For now, I'll leave this person as part of the organization, but I wanted to show you where you
would go to manage that role.
Also, you could click on "Manage access" for a particular user, and then click on "Remove from
organization". Great, now let's click on "Teams".
As a member of any of the teams, you can leave a team, and if you are an owner of the
organization, you can always rejoin a team.
If I click on a team, I can click into settings, and I have the option to delete a team.
I'm going to leave this team intact, but I wanted to show you where you would go to delete the
team in the case that you needed to.
Finally, I'm going to go into settings, and if I scroll all the way down, there are a couple options
that I want to point out.
One is, I have the option to rename the organization.
Renaming the organization is something that has significant repercussions, so I would be very
cautious about doing this.
I'm going to leave this as is, so I'm going to x out of this, and also, at the bottom of the settings
page, I have the option to delete the organization.
Again, I'm going to have to type the name of the organization as a confirmation.
Again, I'm going to x out of this, since I want to keep this organization for later workflows.
Additionally, if I go to my user's profile settings and scroll down, I have an option for
organizations.
From this level, I can also leave the organization.
And, like before, I can go directly to the organization from here or I can click under organization
settings, which would also land me on the organization specific profile page for editing, which
would also allow me to delete the organization or rename it.

Review and Next Steps

In this course, we covered the key concepts and terminology of Git and GitHub.
Additional concepts and topics are covered in our background bonus section.
After that introduction, we quickly installed Git and related tools on our computer system.
Both Windows and Mac were covered, and other options may be added later.
For a more complete installation process with step-by-step videos, see the corresponding bonus
section.
Once we had the theory and installation out of the way, we covered the basic Git operations,
which included initializing a project with Git, and working up to the first commit.
We also covered may file operations, like renaming and deleting files, along with many standard
supporting Git commands.
With a strong foundation in place, we ventured into more advanced territory by comparing
differences, branching, merging, and conflict resolution.
We even covered tagging important milestones and saving work in progress, and even a bit of
time travel with the reset command.
I prefer to make sure we have a good understanding of Git well enough before going remote.
In this case, we use the most popular Git hosting service currently available, and the main topic
of this course, GitHub.
We had a comprehensive look at GitHub, including some features often overlooked.
We looked at repositories on GitHub, social coding with forking and pull requests, GitHub's
issue tracing system, sharing code with gists, and also grouping related repositories together with
GitHub organizations.
This is just the beginning of your journey with Git, both within this course and beyond.
First, I want to encourage everyone to participate within the discussions within this course.
Post any questions you might have, and try to help others too.
I provide support for all my courses via discussions, private messages, open office hours, and
other ways.
I will make minor enhancements to this course by posting tips and tricks, additional lectures, and
updating existing ones when needed, so check back often for updates.
Beyond this course, I do offer several other courses on Git and related topics, so if you like my
style of teaching, please check them out.
Next, there are several great resources available online.