The Version Control with Git course provides you with a solid, hands-on foundation for understanding the Git version control system. Git is open source software originally created by Linus Torvalds. Git manages team files for large and small projects. This allows the team to continuously improve its product. It is used by most major technology companies, and is assumed knowledge for many modern programming and IT jobs. It is a core component of DevOps, continuous delivery pipelines and cloud-native computing. You could also use Git to manage the many continuously improving revisions of that book that you are writing. In this course, you will not learn everything there is to know about Git, but you will build a strong conceptual understanding of the technology, and afterward will be able to confidently dig deeper on any topic that interests you. This course assumes no previous knowledge of Git, but if you do have experience with it, you may find this course to be both useful and challenging. This is especially true if you currently "know just enough Git to be dangerous". There are two paths in this course. Both rely heavily on hands-on labs. One path assumes that you have experience using a command line interface, and the other path uses the Sourcetree graphical client. If you are not experienced with a command line, we highly suggest that you go through the Sourcetree path. Eventually, you might want to go through both paths, so that you can decide which tool to use for specific tasks. Besides, repetition is good for learning :) You can watch the videos and take the quizzes from your phone if you want, but the hands-on labs require you to have a Windows or Mac computer. If you use the command line path through the course, you can also use Linux. This course uses Bitbucket (bitbucket.org) as the hosted provider for remote Git repositories. Bitbucket is free for teams of up to 5 people, including private repositories. However, most of the knowledge that you gain in this course applies to Git itself, and you can apply this knowledge to other hosted Git providers (such as GitHub). This course tries to be as concise as possible. It will probably take you about 5-10 hours to go through one of the two paths, but your mileage may vary.
(Command Line) Branches
Loading...
From the course by Atlassian
Version Control with Git
300 ratings
Explore Related Videos
At Coursera, you will find the best lectures in the world. Here are some of our personalized recommendations for you
From the lesson
Branching and Merging I
This module discusses to of the key concepts involved with Git: branching and merging. It starts with foundational knowledge on Git's commit graph model, Git IDs and references. Branching and merging are then covered, including the difference between fast-forward merges and using merge commits.
Meet the Instructors
Steve ByrnesInstructional Designer
This video discusses Git Branches.
We will start with an overview of branches.
All commits of a project belong to a branch.
By default, commit belong to the master branch.
A branch is a set of commits starting with the most recent commit in
the branch and tracing back to the project's first commit.
In this example, starting from the most recent commit on the branch,
the master branch contains commits B and A.
The feature X branch contains commits C, B and A.
Notice that commits B and A belong to both branches.
Let's take a look at some of the benefits of branches.
We will see that creating a branch is fast and easy.
Creating a branch only creates one tiny file, a reference.
Branches enable experimentation.
Team members can isolate their work so that it
doesn't impact others until the work is ready.
Branches are not aware of other branches.
This allows you to experiment with changes to the project,
while at the same time the team retains a stable version of the project.
If you have an idea for a change,
you can create a branch and test your idea.
Later you can throw out your branch,
or merge it into the official project.
Branches enable multiple team members to concurrently work on the project,
without stepping on each other's work.
Merging the work together later usually is not too difficult.
Branches allow you to support multiple versions of the project simultaneously.
For example, if the project is
a software project with customers on several supported versions,
you can update each version if an important hot fix is necessary.
Branches can be short lived or long running.
Short lived branches are commonly called topic or feature branches,
and usually contain one small change to the project.
For example, a topic branch may contain a new feature, a bug fix,
a hot fix, a configuration change,
or any other change that the project requires.
When it's ready, a topic branch is merged into a long running branch.
In this example, the feature X branch is a topic branch.
Two commits were needed to create the feature,
and then the feature was merged into the master branch.
Long running branches like the master branch live longer than topic branches,
and can even live for the life of the project.
Examples of branches that might live for the life of
a project are a master branch or a develop branch.
We will see later that git branches are
flexible enough to work with many types of workflows.
So you can pick a branching strategy that works best for your team and for your project.
Use the git branch command to see a list of branches in the local repository.
The branch that you are currently on has an asterisk.
You can see here that there are two branches in the local repository,
and the current branch is the master branch.
Next, we will discuss creating a branch.
In addition to listing branches,
the git branch command is used to create branches.
You specify the new branch name as an argument to the git branch command.
Creating a branch simply creates a new branch label reference.
You remain on the original branch.
Here we start with just a master branch containing three commits.
We then create a feature X branch off of the most recent master commit,
by creating a feature X branch label pointing to that commit.
To create the feature X branch label,
we execute git branch feature X.
We then execute git branch,
and see that we've created the feature X branch,
but our current branch is still the master branch.
You can see in the diagram on the right that the HEAD reference still
points to the master branch label after creating the feature X branch.
Next we will discuss checkout.
Check out is usually related to branches and does two main things.
First, it switches the current commit
which is the commit that the HEAD reference points to,
to the checked out branch label or commit.
In this example, if we were on
the master branch and then checked out the feature X branch,
the HEAD reference changes from pointing to the master branch label
to pointing to the feature X branch label.
The second thing that checkout does,
is it updates the working tree with the files from the checked out commit.
Once you have checked out a branch,
you can work on and commit to the branch.
In this example, the feature X label
points to the same commit as the master branch label.
So, at this point the working tree files will be the same for both branches.
Use the git checkout command to checkout a branch or commit.
To checkout a branch,
specify a branch name as the argument.
To checkout a specific commit,
specify it's SHA-1 as an argument.
Here we change from the master branch to
the feature X branch by executing get checkout feature X.
We execute git branch and see that we're currently on the feature X branch.
If we list the contents of the working tree,
we would see that the files for the feature X version would be available.
To create and checkout a branch,
you could first create the branch using the get branch command as we do here.
After executing that command,
you've created a feature X branch,
but the HEAD reference is still pointing to the master branch label.
You can then use the git checkout command to
checkout the feature X branch as we see here.
These two commands in combination create and switch to the feature X branch.
To combine creating and checking out a branch into a single command,
use the -B option with git checkout.
This combines the git branch and the git checkout commands.
This command is only for new branches.
It fails if the branch already exists.
After you've created and checked out the feature X branch,
as shown on the left,
the next commit that is made will be made to the feature X branch.
The HEAD reference moves along with the feature X label,
and the master label stays where it was.
The master branch no longer points to the latest commit.
In fact, the master branch doesn't know about the feature X branch label,
or about the latest commit on feature X.
This is how the feature X branch can make changes to the project
without disturbing the master branch.
Once we have checked out master,
we can do some work in the working tree,
and create a commit.
Now the feature X branch and master branch
both have a commit that doesn't belong to the other branch.
You can see that commit D uniquely belongs to the feature X branch,
and commit E uniquely belongs to the master branch.
Next we will discuss detached HEADs.
Usually you checkout a branch,
which checks out the commit that the branch label points to,
but you also have the option of directly checking out a commit.
For example, you might checkout a commit to
temporarily view an older version of the project.
Checking out a commit rather than a branch leads to a detached HEAD state.
This means that instead of the HEAD reference pointing to a branch label,
HEAD points directly to the SHA-1 of a commit.
So a detached HEAD basically means that
the HEAD reference is detached from a branch label.
Git will warn you that if you continue you will be in a detached HEAD state.
In this example in the before state,
we have the master branch checked out as is normal.
If we then checkout commit B,
that commit will become the current commit,
and the HEAD reference will point directly at commit B,
creating a detached HEAD state.
Temporarily viewing the files of a commit
while in a detached HEAD state is perfectly fine.
However, if you want to work on files of the checked out commit and create new commits,
you should create a branch on that commit first.
On the left, we've checked out commit B,
creating a detached HEAD.
If we want to create commits based off of commit B,
we should first create a feature X branch label,
and checkout that branch.. That puts us back in
the normal state where the HEAD reference points to a branch label.
The next commit will then be made to the feature X branch.
Finally, we will discuss deleting a branch label.
Deleting a branch really just means that you're deleting a branch label.
Deleting a branch label normally does not delete any commits,
at least not right away.
In the example on the left,
we created a feature X branch.
This simply added the feature X label to the latest commit.
If we then immediately delete the feature X branch,
all that happens is that the feature X label is deleted.
This shows how truly lightweight git branches are.
Used the -d option on the git branch command to delete a branch.
Here we start with two branches,
but use the -d option,
to delete the feature X branch.
A call to git branch shows that the feature X branch has been deleted.
Branch labels are commonly deleted after a topic branch has been merged.
Let's take a look at what could
happen if you tried deleting a branch label with unmerged work.
Let's say that you created a feature X branch off
of commits C of the master branch as shown.
Then you did some work on feature X and made commit D.. At that point,
if you tried to delete the feature X branch label,
there would be a problem because commit D does not belong to any other branch.
Git normally will not let you do that.
Here we tried to delete the feature X branch label.
You can see that it responds by saying that the branch is not fully merged.
This means that you could lose some commits that would not belong to any branch.
Git tells you what you can do to really delete the branch label,
which is to specify the D option with git branch.
Let's say that we don't care about commit D and
delete the feature X branch label using the D option.
The feature X label will be deleted,
and you're left with a dangling Committee D. Commit D doesn't belong to any branch.
Git will periodically garbage collect,
looking for and deleting older dangling commits.
So be careful if you use the D option.
It assumes that you want to throw away the work that's in the dangling commits.
Let's say that you accidentally deleted a branch label,
and you left some dangling commits.
You can use a command called git reflog to undo that.
Git reflog is a command that returns a local list of recent HEAD commits.
This list is in the local .git directory,
but not in the repository.
So this only works locally.
In this case, a dangling commit D can be found in the list of recent HEAD commits.
Let's look at an example.
Here let's say that we use the D option of git branch,
and deleted the feature X branch label.
This left a dangling commit.
You can actually see the SHA-1 of the dangling commit in the message returned by git.
Now we will use to git reflog to find that SHA-1.
We execute to git reflog command,
and what is returned is a list of the recent commits that HEAD pointed to.
You can see that the second commit in this list,
is the commit that added feature X.
You can also see that the SHA-1 of
this commit matches the SHA-1 that was displayed by get earlier.
Since that commit object has not been deleted from the object store,
we can copy that SHA-1,
and call get checkout with the -b option,
creating a feature X branch.
That creates a new branch label,
pointing to our previously dangling commit,
and we are back in business.
Here is a review of what we've discussed in this video.
A branch is a set of commits that trace back to the project's first commit.
Creating a branch creates a branch label.
Checkout involves updating the HEAD reference and updating the working tree.
A detached HEAD reference points directly to a commit.
Fix a detached HEAD by creating a branch.
Deleting a branch deletes a branch label.
Dangling commits will eventually be garbage collected.
Now it's time for you to try the things discussed in this video.
Separate hands on instructions are provided.
Explore our Catalog
Join for free and get personalized recommendations, updates and offers.
Coursera provides universal access to the world’s best education,
partnering with top universities and organizations to offer courses online.
© 2019 Coursera Inc. All rights reserved.
