filmov
tv
Introduction to Branches [Learn Git Video Course]
![preview_player](https://i.ytimg.com/vi/Ao1beK2rEIY/maxresdefault.jpg)
Показать описание
Learn everything you need to know about branches - one of the most important features in Git. This video is part of our free 24-part video course on Learning Git on the Command Line.
***************************************
Additional Git tutorials and resources
***************************************
Welcome to our video series on learning version control with Git. In this video, we'll talk about the concept of branches - one of the most important features in Git.
What Are Branches?
First, what are branches at all? They are a bit like "folders". And just like folders, they're used to keep order - to keep separate topics separate. A "topic" can be a new feature that you're starting, or an experiment, or just a little bugfix. In Git, you typically create a new branch for each topic.
Without branches, everything gets crammed into the same context. Commits from all the different topics all end up in the same context.
Using branches, as said, every topic gets its own context where commits are made. And these contexts are kept separate from each other.
Keeping Separate Topics Separate
Why is keeping things separate from each other so important? Let's look at a couple of real-world situations.
New code will - almost inevitably - contain bugs or problems. If you mix this new code with your stable work, it will introduce these problems into your production code. This will affect your teammates because they will also receive these problems. On the other hand, when you keep your new code in a separate context, any bugs in that code will only affect this very context. You can mess up as badly as you might - and neither affect any other context nor your teammates in those other contexts. This is great to know.
Also, keeping separate contexts makes it easier to understand what happened. To stay up-to-date with your project, you need to inspect the commit history. But, especially in a bigger project, you can't have a look at all commits in all contexts. You only need to understand the changes in your contexts, the areas that you're working on.
We've used folders as an analogy to explain branches. Can't we just actually use simple folders? The one thing folders do well is: they create separate contexts. But they are terribly inefficient and inflexible when it comes to managing these contexts.
Branches make all of this very easy:
- They're very efficient because they don't need to create copies of your project files.
- Also, you can easily see what was changed exactly - because all changes are there as a history of commits.
- And you can integrate changes from one branch into any other very quickly - using the "Merge" feature.
- Last not least, they're very easy to manage: creating and deleting a branch is a matter of seconds.
When to use branches?
When you're asking yourself if you should create a branch, the answer is probably "yes". You should create a new branch really for each topic in your project: for a new feature, a new experiment, or just a bugfix.
Pointers and the HEAD
At any point in time, only one branch in your project is currently active. This is also called the "checked out" branch or the HEAD branch. All changes, all commits that you make are made in this branch only.
Also, please note that branches are not optional in Git - you are always working on a branch in Git.
Switching the Active Branch
Now, if there's an active branch, there must be a way to switch to another branch. This is done using the "checkout" command. If you're coming from Subversion, don't confuse this with the "checkout" command there.
So, checkout moves the HEAD pointer to a different branch. It makes that other branch the currently active one.
In the background, a couple of things will happen: Git finds out which commit / which revision this branch is currently at. It then replaces your project's working copy files with the ones that belong to this version.
So, you're now equipped with the basic concepts behind branching and merging. We'll explore all of this in practice in our next videos. See you there!
SUBSCRIBE to learn more about Git, Tower & how to become a better developer!
STAY UP-TO-DATE:
#git #learngit #gittutorial
***************************************
Additional Git tutorials and resources
***************************************
Welcome to our video series on learning version control with Git. In this video, we'll talk about the concept of branches - one of the most important features in Git.
What Are Branches?
First, what are branches at all? They are a bit like "folders". And just like folders, they're used to keep order - to keep separate topics separate. A "topic" can be a new feature that you're starting, or an experiment, or just a little bugfix. In Git, you typically create a new branch for each topic.
Without branches, everything gets crammed into the same context. Commits from all the different topics all end up in the same context.
Using branches, as said, every topic gets its own context where commits are made. And these contexts are kept separate from each other.
Keeping Separate Topics Separate
Why is keeping things separate from each other so important? Let's look at a couple of real-world situations.
New code will - almost inevitably - contain bugs or problems. If you mix this new code with your stable work, it will introduce these problems into your production code. This will affect your teammates because they will also receive these problems. On the other hand, when you keep your new code in a separate context, any bugs in that code will only affect this very context. You can mess up as badly as you might - and neither affect any other context nor your teammates in those other contexts. This is great to know.
Also, keeping separate contexts makes it easier to understand what happened. To stay up-to-date with your project, you need to inspect the commit history. But, especially in a bigger project, you can't have a look at all commits in all contexts. You only need to understand the changes in your contexts, the areas that you're working on.
We've used folders as an analogy to explain branches. Can't we just actually use simple folders? The one thing folders do well is: they create separate contexts. But they are terribly inefficient and inflexible when it comes to managing these contexts.
Branches make all of this very easy:
- They're very efficient because they don't need to create copies of your project files.
- Also, you can easily see what was changed exactly - because all changes are there as a history of commits.
- And you can integrate changes from one branch into any other very quickly - using the "Merge" feature.
- Last not least, they're very easy to manage: creating and deleting a branch is a matter of seconds.
When to use branches?
When you're asking yourself if you should create a branch, the answer is probably "yes". You should create a new branch really for each topic in your project: for a new feature, a new experiment, or just a bugfix.
Pointers and the HEAD
At any point in time, only one branch in your project is currently active. This is also called the "checked out" branch or the HEAD branch. All changes, all commits that you make are made in this branch only.
Also, please note that branches are not optional in Git - you are always working on a branch in Git.
Switching the Active Branch
Now, if there's an active branch, there must be a way to switch to another branch. This is done using the "checkout" command. If you're coming from Subversion, don't confuse this with the "checkout" command there.
So, checkout moves the HEAD pointer to a different branch. It makes that other branch the currently active one.
In the background, a couple of things will happen: Git finds out which commit / which revision this branch is currently at. It then replaces your project's working copy files with the ones that belong to this version.
So, you're now equipped with the basic concepts behind branching and merging. We'll explore all of this in practice in our next videos. See you there!
SUBSCRIBE to learn more about Git, Tower & how to become a better developer!
STAY UP-TO-DATE:
#git #learngit #gittutorial