Captain's log, stardate d274.y40/AB
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!
Some tips on improving self-confidence when developing software projects. Being self-confident helps you writing better code and focusing on what really matters.Read full article
In this post, we explain how the reduce function works and how it can make your development easier, as it is available in all modern programming languages.Read full article
Here's some technical post for the Rails folks out there. If you're into performance optimisation, this is for you!Read full article