×
By the end of this chapter, you should be able to:
So far in our Git workflow we've only been working on a single branch. But when you're working with a team, this isn't usually desirable. What if you want to go off on your own and work on some experimental new feature? It would be nice if you could do so without worrying about breaking the code for everyone else, or conflicting with things that other people are working on.
In most modern work flows, we do not do all of our work on a single branch. Instead, we usually have many different branches for certain use cases (bug fixes, new features, deployment), so it's essential to understand how to create, delete, and merge branches.
Before creating a branch, let's first type git branch
in the terminal. You should see a list of all your branches; right now, there should just be a single branch called master
. This is the default branch for all Git repositories.
To create a new branch we use the git checkout
command with the -b
flag and then pass in a name of a branch. This looks like git checkout -b NAME_OF_BRANCH
.
If we want to move to another branch that has been previously created we use the git checkout
command and then specify the name of a branch. This looks like git checkout NAME_OF_BRANCH
To delete a branch we make sure we are not on that branch and then run git branch -D NAME_OF_BRANCH
To see all of the branches we have, we can type git branch -a
. The -a
flag will include remote branches (branches on GitHub or other remote locations). The flag does not matter right now, but it's good to get in the habit of using it with the git branch
command.
Try creating a branch called second
branch. When you type git branch -a
, you should now see two branches; your current branch will have an asterisk next to it. You can now add and commit files to the two branches completely independently of one another! Try this out by adding separate files to each branch.
With a branch workflow, we usually create a new branch for something we are working on (a new feature, a redesign, etc.). When we are done with that modification, we need to put our code back on the master
branch. Traditionally, the master
branch is reserved for production code and immediate bug fixes. In order to put our code back on the master
branch we need to merge
our code in. Here's what that looks like
Let's:
learn_branching
and cd
into it => mkdir learn_branching && cd learn_branching
.git
repository => git init
.first.txt
=> touch first.txt
.git add .
.git commit -m "initial commit"
.feature
=> git checkout -b feature
.feature
branch, create a file called new.txt
=> touch new.txt
.git add .
.git commit -m "adding new.txt"
.another.txt
=> touch another.txt
.git add .
.git commit -m "adding another.txt"
.git checkout master
. Note that this branch has no awareness of new.txt
or another.txt
!master
branch => git merge feature
feature
=> git branch -D feature
Now if you take a look at git log --oneline --decorate
you'll see that the commit history on feature
has ben merged into master
! (--decorate
gives you nice coloring around branches and where they are in the commit history.)
Here is an example of what branch workflow might look like:
Practice makes perfect. Walk through the following steps to get more experience with the branching and merging workflow.
branch_time
.cd
into that folder. first.txt
, then add and commit the file.amazing_feature
.best.txt
.master
branch.feature
branch into master
.When you're ready, move on to Visual Diff Tools