Start learning with our library of video tutorials taught by experts. Get started
Viewers: in countries Watching now:
The course shows how to use Git, the popular open-source version control software, to manage changes to source code and text files. Using a step-by-step approach, author Kevin Skoglund presents the commands that enable efficient code management and reveals the fundamental concepts behind version control systems and the Git architecture. Discover how to track changes to files in a repository, review previous edits, and compare versions of a file; create branches to test new ideas without altering the main project; and merge those changes into the project if they work out. The course begins by demonstrating version control in a single-user, standalone context, before exploring how remote repositories allow users to collaborate on projects effectively.
In this chapter we're going to be talking about branches in Git. Branches are one of the most powerful features in Git, in large part because of how easy they are to use. It's as if Git wants you to branch, and getting the most out of Git will mean using branches often and effectively. In Git, branches are cheap, and what we mean by that is that they don't cause a lot of headaches. They don't take a lot of processor power. They don't take up a lot of storage space. They are easy to create. They are easy to delete. They are easy to work with. And they allow you to then try new ideas. Let's imagine that you have your master branch that you are working on and suddenly you get an idea for something, but you are not sure if it's going to work out or not, instead of making lots of commits to your master branch and then trying to undo those if it doesn't work out, instead you just create a new branch, try your new ideas there.
If those ideas don't work out, you just throw away the branch, and you haven't tainted your master timeline with those mistakes at all. If it does work out, then you can fold those changes back into the master branch through a process we call merging. Branches also allow you to isolate features or sections of work. This can be especially useful when you're collaborating with others. Let's imagine that we have a web site, and we want to revise the user sign up section, we can create a branch for that separate from our master branch, work on that feature, collaborate with others on that feature, meanwhile other people can still be working on the master branch.
When we finally have our feature all ready to go, and when everyone is happy with it, then we can merge it back into the master branch. This is a very, very common practice when working with Git, you do it all the time. When we create branches we're still going to have just one working directory. All the files that we're working with will still be in that same project folder that we've been in before. But when we switch branches, Git is going to do fast context switching. It's going to take all of the files and folders that are in our working directory and make them match what's in the branch. It will swap out the two sets of changes.
So if we're working on our master branch, and then we switch to our user sign up feature, now our working directory will have all of those user sign up changes in it. We switch back to our master branch, all those changes will go away, and we'll be back to the master branch. Git will handle swapping out all of those files for us, making all those changes, and it does it very fast. Let's take a look at an illustration of what branching looks like just to make sure it's clear. So we have our master branch, that's our default branch that everyone gets to start with, and we start making commits to it. And then after we make four commits, we decide that we want to try revising the navigation, but we're not sure if it's going to work out or not.
So we create a new branch, and then when we finally have all of our changes in our working directory, like we want, we commit those to the new branch. So the commit is now on a new branch, it's not on the master branch. If someone has the master branch checked out, they won't see our changes. We can then switch back to the master branch, and we can switch back to the revise_navigation branch, and each time Git will swap out the files and folders in our working directory to match. So let's say we switch back to our master branch, and we make some more commits there, our revise_navigation branch still is in its other state.
We can switch back and forth between master and revise_navigation, and we'll still get each of those sets of changes. When we're finally ready, and we say, all right, you know what, now I'm ready to merge in the changes from revise_navigation. Let's say it took a week to get approval on my revise_navigation from someone else, but they finally have approved it, a couple of commits have happened in the meantime, but that's okay, we're going to merge it back in, and it will create a new commit, and that new commit will merge in those changes from the revise_navigation branch. So now my master branch contains the changes that we've made in the revise_navigation branch.
Now we can go back to revise_navigation branch and make more changes and merge those back in again. And we don't have to always merge things to the master branch, we could have many branches, and we can merge changes between those branches. Before we dive into actually creating branches, I just want to revisit this illustration again, but I want to talk about where the HEAD pointer is at each point, because I think that's an important thing for you to know right off the bat. So we have our master branch, and we know that the HEAD pointer always points to the last commit in the master branch, the tip of the current branch. Once we create a new branch though, that changes.
We create the new branch, at that point HEAD still points to commit 534de, both the master and revise_navigation at this point are exactly the same. There have been no additional commits made, so HEAD points to the same commit. It's only once we make new commits to the revise_navigation branch that then HEAD moves to a new commit, a commit that's not on the master branch anymore. Now we can switch back and forth. If we switch back to master branch, well then, the HEAD points to the tip of the current branch, that's the master branch.
If we switch back to revise_navigation, it will switch back to point to the tip of the revise_navigation branch. Again, it's like that playhead that's always saying where we're going to start making new commits. So let's say I've got my master branch that I'm working on, that's where HEAD is pointing. I make more commits there. Then when I'm finally ready to merge back in to revise_navigation branch, it creates that merge commit and the HEAD moves to that merge commit. Okay, keep this in mind, because in the next movie we're going to learn how to create a branch, and we'll also take a peek to see where the HEAD pointer is pointing.
Find answers to the most frequently asked questions about Git Essential Training.
Here are the FAQs that matched your search "":
Sorry, there are no matches for your search ""—to search again, type in another word or phrase and click search.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.