Branching in Git: Consolidating Your Work

Version control is vital for helping collaborators integrate different states of edits in a concise manner that is properly documented and accounted for.

Branching is one of the workflows in version control that aids in that very effort. It is essential for preserving previous states of polished work without needing to desperately hit the undo button multiple times if something goes terribly wrong. Here, we will dive into the workflow of branching, specifically with Git.

Let's say that you are on your main branch with a couple of edits and you are ready to commit. In our terminal, we added the file and made a commit with the following commands.

git add README.md && git commit -m "Initial commit on main"

        

Now, let's create a new branch and name it "second-branch" with the following command.

git checkout -b second-branch
        

You will find that the branch name at the bottom left of VSCode will read the name "second-branch" instead of "main". If your first branch still read "master" instead of "main" or you otherwise need to change the any your local branches' name, return to your main branch and use the following command to do so:

git branch -M "[new-branch-name]"
        

Being in this new branch "second-branch", you can now make new changes that will not modify the original main branch. Let's add these new edits to our second branch...

Once complete, commit your changes as you did before with the add and commit commands. You can now safely switch over to the main branch without having our new changes bleed into the main branch. Failing to commit will otherwise result in your new edits spilling over.

At this point, you may notice the inconvenient nature of needed to commit your new edits every time you switch to another branch, as this would clutter your commit history with meaningless commits if you are still working on your next feature. In that case, use the following command to add more changes to the original commit:

git commit --amend --no-edit
        

Note that the --no-edit flag simply tells Git to keep the original commit message.

Once you have finished your new features on your second branch and have made your last commit, you can now push those edits to your remote repository!

Assuming that you have added the remote repository with the name origin (by convention), here is the command to do so:

git push -u origin second-branch
        

The -u switch is shorthand for --set-upstream, which means means to set the branch "second-branch" in your repository "origin" as the branch that your local branch will track. Even if that branch name does not exist on your remote repository on GitHub, it will automatically be created for you.

Lastly, if you want your main branch to reflect the changes in second-branch, you can use the merge command once in the main branch:

git merge second-branch
        

In short, branching in Git will help you protect different versions of your code while attempting to implement new features so you can be worry-free of making breaking changes. I hope this article was helpful to you. If so, please share it with others who are just getting started with Git!