Good/Bad Practices

David Landup
François Dupire

We've gone through a lot so far - the basics of working with Git, working with branches and remote repositories, as well as some advanced operations. We've also covered a few standard ways to use Git on a collaborative project, and included some good practices there.

In all of these lessons, we've tried including notes and disclaimers about certain operations and how to use them responsibly. Such as, which files to include in the .gitignore vs exclude file, or which things to look out for when rebasing.

Now is the time for some general good and bad practices. This will be a more opinionated lesson, filled with the personal experience of the authors and the way they see things right now. They may change in the future, in the light of new knowledge. Be sure to take a step back after reading this lesson and decide for yourself if that makes sense.

Commit Often

What does committing often mean? That means our commits should be relatively small. That facilitates going back when making a mistake.

Let's consider our Calculator project. If we'd implemented all the operations in the same commit, and the fourth operation had a mistake in it. It would've been difficult to just roll back that mistake, or rather - it would be impossible. We'd have to roll back other features as well, which might be important for someone else to use.

Start course to continue
Lessson 9/10
You must first start the course before tracking progress.
Mark completed

© 2013-2024 Stack Abuse. All rights reserved.

AboutDisclosurePrivacyTerms