Slides
Git Branching Work-flows
- When working in Git you will find using branches helpful
- Branches are a core part of Git and can make working with others easier
- There are several general strategies for using branches
Branch Basics
- Branches are a lightweight tool for managing change in Git
-
master
is the name of the default branch - a branch always points to a commit
- which could point to other commits recursively
- eventually all branches point back to some spot on
master
- other branches contain all the changes since they diverged from
master
Example: Branch Basics Diagram
Branching Commands
command | description |
---|---|
git checkout -b x |
create a new branch named x based off the current commit |
git checkout x |
switch to the branch named x |
git branch |
list all known branches |
git merge x |
merge branch x into the current branch |
LAB: branch
We will now pretend to be planning a party. We want to think about the party favors for a while before merging them into the main shopping list.
-
enter your Shopping List repo
cd shopping
-
create a new branch called
party
git checkout -b party
in this branch, add a few party items (like cake or booze) to the list using your text editor
-
make a commit on this branch containing the party items
git add . git commit -m "party stuff"
-
switch back to master. Notice that the party items are now gone.
git checkout master
switch back and forth a few times and see the party items reappear and disappear
Git Merge
-
git merge
takes a branch and connects it to another- usually you merge to and from
master
into a feature branch
- usually you merge to and from
-
to merge is to create a new commit on the current branch
- that "merge commit" has two parents, and represents all changes from both branches
Merge Conflicts
If there are merge conflicts, resolve them. This is a manual process and can be frustrating and confusing. The basic rule is that if there is a conflict, you need to look for lines like this:
<<<<<<<<<<<<<<<<
foo
----------------
bar
>>>>>>>>>>>>>>>>
and then manually edit the files until all the chevrons and dashes are gone, and what's left is correct. In this example, you might choose foo
or bar
, or foobar
, or bar + foo
, or something altogether different. Then git add
the corrected file and follow the instructions on the console to finish the merge.
Merge Conflicts (cont.)
As a more realistic example of a conflict:
<<<<<<<<<<<<<<<<
Hours: M-F open at 9, closed weekends
----------------
Hours: 9:00 am to 5:00 pm
>>>>>>>>>>>>>>>>
This example shows why git cannot automatically resolve intra-line conflicts. As a human, you are the only one capable of making this sort of semantic choice. You must decide whether this file would be better off with one or the other or a creative combination of both changes, and you should communicate with other humans about this decision, in the GitHub discussion thread or face-to-face.
LAB: merge
- on master, add some other non-party-related items to the list, and make a new commit with these items
- merge your party branch into master
- there will probably be conflicts. Don't panic!
- in a text editor, resolve the conflicts
- when you're satisfied, finish the merge with
git add
andgit commit
with merges, it's usually best to run
git commit
without a message since git fills in a good message for merges already. This will open the message in a console text editor, usuallyvi
. If it looks good, exitvi
by typing:q!
- finally, run
git log --graph
to see your commit history with a little ASCII art diagram of the branches diverging and converging
Links
- https://github.com/thoughtbot/guides/tree/master/protocol/git
- https://twitter.com/jezhumble/status/982991911937036288
- http://www.davefarley.net/?p=247
- a branch is a pointer to a commit - cartoon Twitter thread on branches by Julia Evans