“Branch early, branch often”

There is a tip for all Git users: “Branch early, branch often”

It means you should create yourself a habit of using branch when doing anything on a Git repository (doing the new task, fixing the new bug,…)

 But why?

So, why create a new branch? I want to work on my master branch, what’s wrong with it?

Okay, you can work on master, directly. However, this will lead to some hidden trouble, especially when you work in a team.

Let’s say: when you are working on a cool feature for the website, a customer suddenly called to ask you to fix an urgency bug. What will you do? Use git stash to backup your changes then revert the code to the original version and fix the bug? Of course, this will solve the problem, but it is not the proper solution at all. It might make some conflict when you revert your code from stash after fixed that bug. Or something weird will happen during the code merging.

To avoid these troubles, we can simply create new branches for these tasks.

 How it works?

Let’s see how it works in the comic below:

It is a new working day, and you are in the daily stand up. You picked some awesome tasks.

The first thing to do is create the new branch for your task with git checkout -b:

Keep commit your work as regular as you can, but no need to push them yet.

For sure, when you are working, the customer will call you for some help anytime, no worry, he just needs you to add some features or fix some bugs, or many… don’t be panic…

Because you can’t decline his requests, let’s finish them first, then get back to your work later.

Just make a new commit for your WIP code, then use git checkout to jump back to the master branch.

Don’t forget to use git fetch or git pull to get the latest code to your master branch before you continue with the fix.

Now, create a new branch from master, let’s call it change-font, because the customer wants to change the website’s font family.

Do the fix, and when you are finished, commit it.

Get back to master branch and merge your changes with git checkout and git merge:

Now, your commits now merged into the master branch. You can push them to the remote and do the deploy, ask the customer to check the result. Then, back to your awesome WIP features (US-111).

Finish your work and commit it.

It’s 6:00 PM, let’s merge your work to master branch and push them to the remote. Time to go home! Your working day has been finished!

 So, will you branch?

It seems to take a lot of steps, may be it’s too complex for you, but believe me, dealing with conflicts or losing your code is much is worse than this.

Will you spend few minutes to create a branch or spend few hours just to revert your missing code back?

You can use some Git client such as SourceTree or GitX to have a visual commit graph, it’s much better. But using command line should give you a better Git knowledge.

Finally, let’s end this article by looking at this graph, could you remember which command was used in each commit?


Now read this

Recursive type problem in Rust

After spending much time reading about Rust, I decided to give it a try. It was a very simple implementation of Binary Tree Traversal algorithm. Surprisingly, by doing it, I learned a lot of Rust’s basic concepts! Rust tell us what’s... Continue →

Subscribe to The Full Snack Developer

Don’t worry; we hate spam with a passion.
You can unsubscribe with one click.