On the ninth day of Christmas my true love gave to me… nine versions a-keeping.
In the previous lesson, we learned about using Git to experiment safely by creating new branches and adding commits to a specific branch. Today, we’re going to use the new branch we created in that last lesson to learn about using remote branches with Git.
If you are following our song, “The Twelve Days of Git,” here are the verses so far:
- The 12 Days of Git: Learn Git over the Holidays
- The 12 Days of Git, Day 2: Tracking Files with Git
- The 12 Days of Git, Day 3: Viewing Git History
- The 12 Days of Git, Day 4: Double-checking Changes with Git
- The 12 Days of Git, Day 5: Sharing Changes Remotely with Git
- The 12 Days of Git, Day 6: Making a Copy of a Git Repository
- The 12 Days of Git, Day 7: Keeping Your Git Repository Up-To-Date with Others’ Changes
- The 12 Days of Git, Day 8: Using Git to Experiment Safely
You’ll remember that we had created a new branch in our repo called father-christmas. In the repo folder, check that you still have that branch checked out.
You should see the following output.
* father-christmas master
If the asterisk (*) is not beside the father-christmas branch, run the command
git checkout father-christmas.
Once you are on the new branch, you can use the following command to copy that branch to your remote repo.
git push -u origin father-christmas
You will see output like this.
Counting objects: 3, done. Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 375 bytes | 0 bytes/s, done. Total 3 (delta 1), reused 0 (delta 0) To https://github.com/vjwilson/santa-tracker.git * [new branch] father-christmas -> father-christmas Branch father-christmas set up to track remote branch father-christmas from origin.
This is the same
push command we used in an earlier lesson to copy our master branch to the remote repo. Now, we have specified a different branch, father-christmas, to go to our origin remote. The -u option lets Git know that if you have this branch checked out, you want Git to copy down any changes from the remote when you do a
git pull. (There may be changes you don’t have if you are collaborating with others, and they are pushing their own changes to that remote repo.)
When you look at your remote repo’s page on GitHub, you will see that it lists two (2) branches in the info bar. If you’ve recently pushed changes to a branch, there will be a box labelled Your recently pushed branches. Finally, you can click on the Branch dropdown menu to see a list of all your branches. If you click on a branch name in that menu, your view of the repo will reflect the changes that are in that branch.
Just as you use
git checkout on your local machine to switch between different versions, on GitHub you use that branch dropdown menu to switch between branches. To see how this works, while you are still looking at the master branch, click on the
index.html file. You should see the code listing for the file as it appeared in the last commit to master. Notice that the
<h1> elements start with the word Santa.
Now, while still viewing this file, click on the Branch dropdown menu and then click on the father-christmas branch.
The code listing for the file will now show the last commit to the father-christmas branch. Notice that the
<h1> elements now start with the word Father Christmas.
If you and another person are collaborating on an experiment, one of you can create a branch for that experiment and push it to a remote repo you share. Then, the other could pull down a copy that branch, just like you pulled changes from an upstream repo on Day 7. You both could edit files for that branch, and periodically push your new edits back up to the remote. Each of you would be responsible for sharing your changes and pulling the other person’s changes.
Once you both had a copy of the branch that was linked to your remote’s branch, the command to get any changes to that branch that are on the remote is simple. While you have that branch checked out, just use this command.
If the branch is checked out, and you are sharing it through your origin remote, you don’t have to specify the remote or the branch name, as we did in pulling changes from the upstream Bootstrap repo in the earlier lesson.
You may be wondering what happens if both you and the other person make changes to the same file and try to push those changes up. Git won’t let you overwrite another changeset. One of you will push your changes up first, and then when the other tries to push, Git will tell you that you have to pull before you can push.
Say you two have changed different lines in the same file—you changed the
<title> and the other person changed the
<h1> line—then Git will try to merge both set of changes together automatically when the second person pulls. This is an extremely helpful feature of Git.
However, if you both have changed some of the same lines, or you have changed so many lines that it is hard to tell how the changes would fit together, then Git will need your help to merge them. Check back tomorrow, when we’ll learn about The 12 Days of Git, Day 10: Merging Different Versions with Git.
To see all the options available for the commands we’ve discussed today, check them out in the online Git reference: