Basic Git Branching
Basic Git Branching
In this article, we walk through the basics of branching with Git to get you started with better managing your versioning during projects.
Join the DZone community and get the full member experience.Join For Free
Dr. Banner (Hulk) talking with the Ancient One about alternate timelines in regard to the Infinity Stone in "Avengers: End Game" is a perfect example of branching in Git. But, instead of source code, they were talking about time travel and alternate realities. Branching is a very useful topic in software version control, and I believe most people are aware of this idea even if they are not from a software development background.
Branching in Git is very powerful but can be overwhelming at the same time. Git branching covers a lot of workflows and scenarios. In this post, I will try to introduce you to a very basic setup that will help you can use to get started with branching and much later down the line as well.
Git branches are effectively a pointer to a snapshot of your changes.
You may also like: Top 20 Git Commands With Examples.
Local vs Remote Branch
In this post, I will focus on local branches (the branches that live on your development machine), but the concepts are the same for remote branches. Normally, when you start developing a task, a bug fix or a new feature, you can create a new branch for that activity, do all your work in that branch, commit changes to that branch, and once done, merge those changes back to the master branch. So, let's see how we can start with this basic branching setup.
Step 1: Create a New Local Branch
git branch -v, is one way to list all the branches for your repository. In our case, we only have one master branch. Let's say we want to start working on a new feature in software, which we'll call “feature1”. We can create a new branch for this feature as shown below:
This command creates a new branch, named "feature1", and makes that branch our active branch.
Step 2: Code Changes, Commits, etc.
Step 3: Back to Master Branch
Once you are done with your changes for "feature1", you can switch back to master branch with the following command:
Optionally, it is also good if we execute
git pull origin master to get any changes from the remote repository.
Step 4: Merge the Feature Branch to Master
Now, our changes are on "feature1", and we have switched to master. We can use
git merge feature1, and that will merge changes from "feature1" branch to master.
Step 5: Delete the Feature Branch
Once we have successfully merged changes to master, we can delete our local branch, and that's it. The whole purpose of this branch was to make code changes in isolation. Once those changes have been amde, we can delete with the branch with the following command:
git branch -d feature1.
Step 6: Push Changes to Master (Remote)
This step is also optional. If we like, at this point we can push changes to master (remote) so other colleagues could pull these changes as well.
git checkout -b feature1(create a new branch, called "feature1").
git checkout master(switch back to master branch).
git pull origin master(pull changes from master, optional).
git merge feature1(merged "feature1" branch back to master branch).
git branch -d feature1(delete the local branch after merge, optional).
git push origin master(push changes to remote master, optional).
The above-mentioned steps are all you need to start with Git branching. I will suggest that you adapt to this strategy for every code change, bug fix, or new feature. Create a separate branch for that locally. It will simplify things for you a lot.
Once you are comfortable, you can explore other advanced topics related to Git branching. There is a nice article by Vincent Driessen, which allows you more control and cover some advance use cases, I will suggest that approach if you are dealing with complex workflows. You can access the article on https://nvie.com/posts/a-successful-git-branching-model/.
If you need more information or if something is not clear, feel free to ask, and I will try to answer. Til next time, happy coding!
Opinions expressed by DZone contributors are their own.