1.2 Git Basics: Branches
In this lesson, I’ll teach you how to use
git branch for fast and efficient management of your source code. Follow along and I’ll show you how to use branches and how to keep them synchronized to a remote server. So that you understand the concept better, I’ll also explain how they are implemented by Git.
Create a new branch and check it out with the following line of code. It’s that easy!
git checkout -b new-feature-branch
If you want to push this branch to a remote Git server, e.g. GitHub, use:
git push origin new-feature-branch
Finally, if you want to merge the branch back into
git checkout master git merge new-feature-branch
1.2 Git Basics: Branches
The whole Git workflow is built around creating and fusing branches together. Branching is a killer feature of Git. As a beginner, it is important to understand its power and potential. Branching at Git is not only very easy, it is also very cheap. We always have a main line for development, the master branch. But we can create an endless number of branches without any serious side effects. Except that house keeping is a good idea. With the branch we can safely diverge from the main line of development and work up new features that can be proposed to be integrated into the massive branch. If acceptable, it is just a merge or rebase away from getting into production. If on the other hand the work on the branch does not fulfill the requirements needed, you can simply continue your work on that branch or abandon it altogether. What is a branch? A branch is a plain old file that contains the 40-character hash of the commit it points to. That's why people say the branches are cheap and easy to create, all it takes is 41 bytes. Being able to branch that easy and therefore that often makes our coding lives a lot more efficient and stable. Switching between branches is not only super fast you can easily switch between branches using the git check out command. Master for example is nothing else on the branch itself. It's just a convention to call that particular branch master. When you run the get init command this master branch gets created for you as a default. We can have local and remote branches. Let's talk about local branches first. You create a new local branch, simply by tapping git branch with the branch name. This creates a new pointer that can be occupied by head. You only created the branch though and didn't switch to it. It is accomplished with the git check out command, the shortcut to create a branch and switch to it at the same time is git checkout b with a branch name. One step instead of two. So when you switch to a new branch, head is coming along. We've covered head in another short video but I should say this. In this context git users had to know which branch we are on. When you switch branches you also change the index and working directory underneath. It adjusts to the history of a particular branch. This is important to understand as a beginner. Your working directory and your index are changing all the time when you check out various branches. The files adapt to the respective state, represented by the leaders commit head is pointing at, at any given moment. That way you can easily switch between contexts and recreate all kinds of different points in time for development. Branches also act as discrete silos for your work. They're not interrupting each other. The different versions of your work are separated by the branches you create. Every branch is a silo of its own until you have used them into each other by emerge or rebase of course. What is cool about branching is that it can do a lot of different work in parallel. Say you're working on some database issue on one branch and some front-end code in another. Both of these or even more branches can exist simultaneously without affecting each other in any way. You can switch between branches whenever you decide to work on something specifically. Also, branches can be kept around as long as you need them. So far we've only discussed branches that are local to your computer. We can expand our branches into the cloud via remote branches. Remote branches point to the state of branches that are part of some remote repo, something like GitHub for example. You can set up your own Git server as well of course. You can can see these remote branches as bookmarks and backups. Services like GitHub are much more sophisticated and powerful, but at their core, they function as Git servers. That way, you can communicate and share your commits through a centralized hub that you share with your team or the public. Your own remote repo has a default name. It's called Origin. You can name it anything you like,of course. We identify a branch by prefixing it with that server name like Origin/Master for example. How do you create such a remote branch? When you fork or clone a repo you will have automatically access to the branches that are on that remote repo. Git creates the necessary references for you. All the dataset remote repo are holding or pull down. It creates a local master for you that has all the info from the remote repo. That way you can immediately build upon that. With remote branches you gain access to the worker photos and vice versa of course. You update these remote branches by pushing to them. They don't automatically update when you commit locally. When you check out that local version of it you can push to the remote branch simply by using the Git push command. Of course you can only push if you have write access to that remote repo. Once branches are up on the Git server, they're ready for collaboration. When somebody fetches from this shared repo, they will have a reference to that new branch of yours. They can fetch it down and check it out as well. The branches that you wanna share get pushed up to some remote repo. The branches that stay on your machine are private. Other team members have no access to them until you push them as well.