Two golden practices in collaborating with
masterbranch functional at all times
git relies on branches. They allow our "golden
practices". Let's explore
git branches and we'll come back to review why
these golden practices are so helpful.
git branch is a means to separate a new set of commits or edits from
another branch. Typically we create a new branch off of
master. If all
developers we collaborate with honor Golden Practice 1, we can trust that
master will be a safe starting point.
When we branch, we're creating a separate parallel universe. We can experiment there without any bad effect. It's a contained sandbox where mistakes can be made or ideas can incubate.
It's an idea that a lot of fiction has presented in the last 50 years.
|Mirror Dimension||Dr. Strange (2016)|
|Darkest Timeline||"Community" / "Inspector Spacetime"|
|The entire premise of..||"Dr. Who"|
|Mirror, Mirror (Evil Kirk / Spock)||Star Trek|
|Plot Against America||Philip Roth|
|The entire plot of...||"Primer" (2004)|
If you understand multiple-timeline fiction, you get the idea of branches.
By doing work in branches, all collaborators can do work without messing with
the main line known as
master. OK, so how can we actually leverage this
Best practices suggest that any new set of changes related to fixing a bug, creating a feature, or even messing around with experimental code in a "sandbox", should be started on a new branch.
In order to start a new branch, in the terminal type:
git branch <branch name>
to create the newly defined branch.
This creates a new branch which can be seen in the branch list by typing
branch in the terminal.
In the case of a branch relating to writing a new feature, you could name the
git branch add-rainbow-background.
This will take the entire commit history of the branch you're on (usually
master) and make it the same history as on the
At this moment
add-rainbow-background are the same branches /
realities etc. As you add more commits on the feature branch you're changing
add-rainbow-background reality. The
master branch will not be
changed. Let's talk about adding those commits.
In order to start making changes on your new branch, you need to "check it
out." After checking a branch out, your commits will be added to that branch's
history. You move between branches with
git checkout <branch name>.
PROTIP: You can create and checkout a new branch in one command using:
git checkout -b new-branch-name. That will both create the branch
new-branch-nameand move into it by checking it out.
If you are currently on
add-rainbow-background, you can move back to
git checkout master. You can also type
git checkout - in order to move
back to the previous branch.
When you add commits to a branch, you can see the history of the commits by
git log --graph. The
git log command displays the history of commits
for the branch you're on. The
--graph "flag" tells
git to make it pretty,
like a timeline. You can use "Space" to page down the history of commits. Use
q to exit.
To make sure that you don't lose work, you should make sure all your changes
are committed before you switch branches. If you're doing work in
add-rainbow-background that updates
master also has
master could overwrite your changes. Make sure all your
changes are committed before you switch branches.
githas a powerful feature called
stashwhich can be used, when you're ready to hold changes-in-progress. When you're very comfortable with
git, look into it!
If we then
git checkout master, and use
git log --graph again, we will see
master branch only has the code up to the moment you "branched"
add-rainbow-background timeline, er, branch.
The code from our
add-rainbow-background is tucked away in that branch,
waiting patiently in isolation from the rest of your code in
master until the
feature is considered complete.
The final step of completing the
add-rainbow-background work is to merge that
branch into the
Now that you have some additions to the code that you'd like to combine back
master, the goal is to bring the branch of commits that occurred on
add-rainbow-background branch into the
master. By merging the branch,
master will have all of the commits from the
as though those events occurred on the
When merging a branch with
git merge, it's important to be currently working
on your target branch, the branch you want to gain the content of the feature
branch. The first step for our
add-rainbow-background merge is to checkout
master because that is where you want the commits to end up.
git merge -m "merge in feature add rainbow-background" you
add a message and complete the commit in one action.
Now the branches have been merged. If you type
git log --graph, you'll see
the commits from the
add-rainbow-background branch on your master branch.
When you're done with a branch that's been merged you can delete it with:
branch -d branch-to-delete.
Your local branches can merge in changes from remote repositories branches just like they can do for local branches!
To update a list of available branches at a remote we use:
As a shorthand to
fetch and then automatically merge the same-named branch
from the remote we can issue
git fetch remote-name branch-name-to-merge-in.
These are complex topics as it brings up the issue of how to reconcile lines of
code where you and another developer might have changed the same thing. This is
called a "merge conflict." We're not going to cover that topic here. Instead we
want you to embrace working in branches, keeping
master functional, and doing
local merges. To give you a preview of what merging a remote branch workflow
$ git fetch origin $ git checkout add-rainbow-background $ git merge origin/laurens-rainbow-idea
And now our local
add-rainbow-background has Lauren's ideas woven into it.
As developers we try to make sure that everyone has a clean place to start
from: be that for writing a new feature or fixing a bug. Branching lets us keep
master working at all times. If an emergency bug comes up, we know we have a
solid foundation to build from. Feature branches also help us look at
log and see what the intention of a feature was.
Git is a complex tool, and these tools are just scratching the surface for
collaborating with people. These workflows are just being introduced to
you--and it may be challenging for the time being. You'll have lots of time to
practice them and get used to what each command does. Don't try to cram it
all in at once; instead just start to get an understanding of what is at your
Do not do as stick man suggests!
View Git Collaboration on Learn.co and start learning to code for free.