Category: Git

[FxOS] Why we need to squash commits ?

This is what I found in our Taipei office “Squash bugs for a better (Life) Web”

squash

Concepts about version control

When using version control tools like git, hg … etc , we all have one common concept in mind that we have to commit often to make sure all stuffs can be tracked and understandable when reading histories. By doing so, sometimes we may break a bug to many chunks and this would make us hard to track at the first glimpse. All you can do is trying to find the first commit about the bug and keeps reading commit by commit to know the whole story.

For personal / small project, I think this is ok. But for a big project like Gaia or some other open source projects, this would not be a good idea to do so.

In Gaia

Go check Gaia repository first, you will notice there are more than 35,000 commits and 470+ contributors in this project. To be honest, this is really a huge repository. There are so many people working at the same time in different timezones trying to make FirefoxOS better, so there must be really hard to control. But after being part of Mozillian, I finally understand how they try to maintain it.

 

commit

Our latest commit history

As you may see, for us, each commit will be reflected to one bug with bug number on the title. By doing so, we can easily understand what this patch is for and what it is going to fix. With bug id, I can easily search Mozilla’s bugzilla to understand the discussion histories and design specs there.

In addition to this, if each commit is mapped to each bug, then we can easily revert any patch that broke Gaia! For example, you can check the picture and notice that there is a revert commit made by crh0716. That’s because the patch broken something in Gaia, anyone can go ahead and find out the patch then back it out !

It’s amazing, isn’t it ?!

So, how to squash commits !?

If you read this line, it means you did read the whole article and want to know something about this ! From my experiences, I noticed there are less people knowing how to do this (I met few contributors and they all messed the git history up in the end xD ! It happens every time LOL).

So, I made a quick screenshot to help you understand how to do this. Just to remind you, there may be some other ways to achieve this, but this is how I do in my daily life.

Hope this helps ! And any feedback or comment is appreciated ! Cheeeeeers !

https://asciinema.org/a/11269.js

[Git] How to maintain a huge and long-lived branch

pr

Story

Currently I am maintaing a god damn long-lived and huge branch on my local and for me, this is xxxx annoying -_-. Here comes a tip first, please make sure to break down your patch as much as you can. For me, this patch looks kinda independent and tiny enough, but I am wrong in the end.

As you can see, this branch has changed almost 60 files in the codebase and change of LOC has increasing to 5000 ! So, you can definitely guess that there must be so many conflicts happened especially Mozilla/Gaia is such a huge open source project and is contributed by lots of hackers from different timezones in this world. Based on my observations, it can hit more than 5000 LOC changes like features, bugfix … etc per day !

But, this case helps me to get familiar with how to keep your branch up-to-date with main trunk and I already came up with a small SOP to help me on this. In order not to forget this important experience (I don’t think I will forget xD), I would write them down about how I made it.

SOP

  • git checkout -b bug-973466-backup-20140619
    • Make sure to backup one copy of your current branch in case of something broken when rebasing. In my case, because I have to keep it up to date with main trunk all the time, it would be better for me to use Date format to make it readable and easy to identify.
  • git checkout bug-973466
    • Jump back to current branch
  • git rebase master
    • Rebase your code onto master to keep updated with it
  • Solve conflicts
    • You will find so many conflicts in this stage, and please don’t be afraid, use github / git diff / vimdiff or anything whatever to make sure there is nothing broken in this stage and both of theirs and ours changes are still there.
    • If you got lost in this stage, just did git rebase --abort to exit the process and there is nothing influenced ! Yeah.
  • If you successfully solve conflicts and nothing is wrong, it’s great ! You are free now !
  • If you found something wrong later after rebasing, it’s too late to recover, that’s why we need a backup ! Just remove your current branch and replace it with backup one, nothing is broken now ! Nice !

Some thoughts

  1. Don’t make your branch huge and try to break it down to smaller parts.
  2. If your current move is danger and hard to recover, always remember to make a backup.

Hope these information helps ! Any idea or feedback is welcome !