New terms from treehouse – Git Basics Part 2 – Merging, Working with Remote Repositories, and Workflowst


Intro to Merging

This how you get your branches back together, it’s like the opposite of branching. It merges all of the branches’ changes and commits into one cohesive timeline. The other branch doesn’t go away, and you can keep merging and working on it as long as you like, you’re just copying the commits from one branch into another.

If a file was changed in both branches, this is called a merge conflict and you need to decide which one to keep. Git does its best to auto resolve these for you, and if it can’t it will ask you.

Basic Merging

If you don’t have conflicting changes between two branches, merging can be done easily. Let’s merge foo_feature back into master. Start with git branch to see where you are, and make sure you’re in master. Then, use the git merge command followed by the name of the branch you want to merge into the one you’re in now.

Screen Shot 2014-11-04 at 3.57.49 PM

Let’s set up some merge conflicts by changing the README in our two branches.

Screen Shot 2014-11-04 at 4.01.38 PM

Since they were on different lines, git auto merged them for us. Both commits are now listed in master. It does this by creating a new automatic merge commit.

Screen Shot 2014-11-04 at 4.02.43 PM

Remember that the foo_feature branch is still around, and that the merge only affected the master branch.

Merge Conflicts

Here, git will present you with the conflict and ask how you want to handle it. We’ll set one up by making changes to the same line in file1.

Screen Shot 2014-11-04 at 4.09.13 PM

When we go to merge, we get this conflict message.

Screen Shot 2014-11-04 at 4.10.49 PM

To resolve this, you can just edit the conflicted file so it matches. If we open file1 in our text editor we’ll see conflict markers which show us where the conflict occurred. The angle brackets surround the conflict, and the equals signs separate the two versions.

Screen Shot 2014-11-04 at 4.13.11 PM

You can just remove the conflict markers and save that if you want, delete the change from one of the branches, or combine them, which I’ve chosen.

Screen Shot 2014-11-04 at 4.15.02 PM

Now, we need to add our commit to the staging area, then run git commit.

Screen Shot 2014-11-04 at 4.16.16 PM

Git knows we’re correcting a conflict, and has created a useful commit message for us.

Screen Shot 2014-11-04 at 4.16.52 PM

Screen Shot 2014-11-04 at 4.17.44 PM

Working with Remote Repositories

Working with Remotes

If someone needs to work on a project with you, they can’t use your repository because it’s on your computer. But, they can make a copy of yours for their computer, and this is called cloning.  Later, after you’ve both worked on it for a while, you can merge your copies of the repository, much like you would merge branches. You’d have a central repository on a server somewhere that is the official version of the code.


In this example, we’re going to clone a repository on our computer, but cloning a remote one would work the same way. You can clone a repository using the git clone command, followed by what to clone. You can optionally add what you’d like it to be named after that.

Screen Shot 2014-11-04 at 4.39.46 PM

If we look inside our new directory, we’ll see it’s a copy of our files, and we can access the git log just like before.

Screen Shot 2014-11-04 at 4.41.09 PM

Git also automatically set up our original repository, named origin, as a remote one when it set up this new one. The git remote command lets us see all the remotes available to this repository. In this case, there’s just the one called origin.

Screen Shot 2014-11-04 at 4.43.12 PM

If go to our original repository and run the git remote command, nothing gets printed out, which means the original repository isn’t affected at all by the clone. This is good, because if a lot of people were making copies, you wouldn’t want to have have it affect the original every time.

Screen Shot 2014-11-04 at 4.45.10 PM

Still to get the origin to notice and be able to talk with the remote one, use the git remote add command. Note that you can choose a name for it, in this case “our_clone”.

Screen Shot 2014-11-04 at 4.48.56 PM

Pushing and Pulling

We’ll start by creating a new branch in our cloned repository, then changing file2’s text and committing it.

Screen Shot 2014-11-04 at 4.52.52 PMTo get this back to the remote repository, we can push our change using the git push command, which should send all of our changes to there.

Screen Shot 2014-11-05 at 1.39.04 PM

It says everything is up to date, which seems like nothing happened. This is because the new_feature branch we created doesn’t exist in the remote repository yet. Git doesn’t know it needs to be tracking changing in that branch across both repositories. You need to explicitly say that by adding it to the git push command.

Screen Shot 2014-11-05 at 1.41.17 PM

Once again an issue. By default, the first argument you provide git push needs to be the remote. Otherwise, it will assume you’re referring to git origin. Seems we need to explicitly state that here.

Screen Shot 2014-11-05 at 1.43.31 PM

If we switch back to our origin repository and check it’s branches, we can see it’s now there. If we were to check its git log, we’ll see the commit for file2 there as well.

Screen Shot 2014-11-05 at 1.44.27 PM

Let’s say the person working on the origin didn’t like the change to file2 in the new_feature branch and wants to edit it. They do that, then switch back tot he master branch.

Screen Shot 2014-11-05 at 1.49.26 PMMeanwhile, the other dev is working in their clone project repository, and edits file2 again. We’ll then push the change to the remote.

Screen Shot 2014-11-05 at 1.52.40 PM

But, we get an error saying that our file is not up to date, so we can’t push. We can update our end with the git pull command. It takes two arguments, the remote to pull from, and what branch. It tries to pull it over and gets a merge conflict error.

Screen Shot 2014-11-05 at 1.54.38 PM

Pull works like merge, the difference being instead of pulling in changes from another branch, it grabs them from another repository. Time to resolve the conflict by editing the file2 with nano, and picking what we want to keep.

Screen Shot 2014-11-05 at 1.56.21 PMScreen Shot 2014-11-05 at 1.57.11 PM

We save, add our file to the staging area, and then commit it. We confirm our git message, the try git push again.

Screen Shot 2014-11-05 at 2.00.30 PM

Back in the master, we’ll make an edit to file1 and commit it, then try running git push.

Screen Shot 2014-11-05 at 2.01.43 PM

We get an error about no configured push destination, so let’s add that.

Screen Shot 2014-11-05 at 2.03.36 PM



Git-flow is a sub command you can install for git. Once installed, we’ll add a new branch, then initialize it using the git flow init command, which will ask you a series of questions about your preferred workflow. First you choose what will be your production branch. In this case we’ll choose master, which is the usual choice.

Screen Shot 2014-11-05 at 2.41.29 PM

Next it asks you to set the branch for integration of the next release, where features will go when they’re finished, but before they go live on the site. This is what we created the integration branch for.

Screen Shot 2014-11-05 at 2.43.00 PM

Next it asks you about branch prefixes. Git-flow’s model is to handle everything by creating a branch, which can be overwhelming if you’re not careful with the organization of them. These prefixes help to categorize the branches.

Screen Shot 2014-11-05 at 2.45.36 PM

Next it asks you about the version tag prefix. Git allows you to add tags for your commits. Anytime you move a change to the master branch, git-flow will tag it with a special message so you can find it later.

Screen Shot 2014-11-05 at 2.54.02 PM

The initialization process is done, and now you can use git-flow. To start a new feature, enter git flow feature start, then the features name. You’ll see it tells you the branch was added with feature/ before it, in the integration branch. It also tells you what to do when you’re done.

Screen Shot 2014-11-05 at 2.55.24 PM

When you’re done, it will merge the branch into the one specified and switch you to it (integration in this case), as well as delete the branch you were working on.

Screen Shot 2014-11-05 at 2.57.04 PM

To make a hotfix, it works the same way, only you use the command git flow hotfix start, then its name. Note that it’s based off the master branch this time, because it’s a hotfix.

Screen Shot 2014-11-05 at 2.59.29 PM

When you’re done, finish it the same way as before.

Screen Shot 2014-11-05 at 3.01.19 PM

Git-flow will prompt you for a tag message, save, and you’re good to go.

Screen Shot 2014-11-05 at 3.02.30 PM

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s