Merging
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.
Let’s set up some merge conflicts by changing the README in our two branches.
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.
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.
When we go to merge, we get this conflict message.
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.
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.
Now, we need to add our commit to the staging area, then run git commit.
Git knows we’re correcting a conflict, and has created a useful commit message for us.
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.
Cloning
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.
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.
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.
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.
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”.
Pushing and Pulling
We’ll start by creating a new branch in our cloned repository, then changing file2’s text and committing it.
To 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.
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.
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.
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.
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.
Meanwhile, the other dev is working in their clone project repository, and edits file2 again. We’ll then push the change to the remote.
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.
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.
We save, add our file to the staging area, and then commit it. We confirm our git message, the try git push again.
Back in the master, we’ll make an edit to file1 and commit it, then try running git push.
We get an error about no configured push destination, so let’s add that.
Workflows
Git-Flow
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.
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.
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.
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.
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.
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.
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.
When you’re done, finish it the same way as before.
Git-flow will prompt you for a tag message, save, and you’re good to go.
Kyle's Awesome Awful Websites 