Captain's log, stardate d274.y40/AB

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

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!