Iterating on pull requests - don't squash commits!

Captain's log, stardate d274.y40/AB

This is a small piece of advice for starting developers regarding pull requests on git.

Motherboard - Photo by  Alexandre Debiève

I would like to share how we like to work with pull requests and commits at MarsBased because I have seen it's something that new developers aren't taught and it might create a bit of friction at the beginning. Especially those that have learnt by themselves and/or have never worked as part of a bigger organisation/company, where these things are typically pretty well defined.

When you make changes to a PR after a code review, don't squash the commits. Instead, create new commits on every iteration of the code review process, without overriding previous ones.

This slight change of approach makes it easy for the code reviewer to focus only on reviewing the last changes made since the last review. Otherwise, if new changes get merged with old changes it's very difficult to know what has changed since the last review, thus replicating work and adding more to the reviewer's plate.

Once the PR gets approved, then we squash all the commits into one (there may be more than one if it makes sense for a large PR) to leave a clean history.

If you are interested in reading more, make sure you check out our Git guidelines from our company Handbook!

That's all from me for today! Thanks for reading!

Oriol Collell Martín

Oriol Collell Martín

Chief MartianTapas Officer. Before MarsBased, he was co-founder and CTO at Dineyo, which honed his entrepreneurial skills. Passionate hooligan of Startup Grind & Muns. Every company has got a troll, we've got Oriol.

comments powered by Disqus

You're one step away from meeting your best partner in business.

Hire Us