Git: I love “git pull — rebase”. How about you?

Hi there! Welcome to my blog, this is Alan.

Today, I am sharing with you my experience with “git pull –rebase” which I always use when working with a team.

Have you ever tried it when pulling updates from the main branch to your working branch? Give it a try and you may love it too.

I used to use git pull with default setting “merge” for many years and it worked well for me until I joined a big company and luckily I met a good team leader, he told members using “rebase” instead of default setting “merge”, because it keeps the history tidy and easy to track back.

At the first time, I was like, is that really helpful? Keeping the history path clean and for tracking back, we just simply go back, why do we need it clean? 😆

But after leaving that company and my organization skills have been improving, I started loving it.

I love using it because, to me:

• It makes your commits look tidy, in sequence without mixing commits of others in between, all of your commits are always the latest in the history path when pulling updates.
• When you want to soft reset and merge many commits into one, piece of cake!
• Tracking back or resetting will be much easier after your PR is merged to the main branch, because all of your commits go in sequence without other commits in between.

Press enter or click to view image in full size

rebase and merge

That’s all the reasons and it works best for me. You may like it or you may find the “merge” option more suitable for you. Either rebase or merge, I think as long as the one helps you work effectively, it will be your best choice.

I hope my opinion will give you another view of using git pull.

Thanks for reading!