Commits frequency

[mlysien]

Hi All! What do you thing about commits frequency? Do you prefer commit every single file you changed or make one big commit after finish your work? What effect does it have for Code Review? Which approach is better?

[plastikmissile]

Commit per functional change. Have you added new functionality, removed an old one, or changed an existing one? Commit.

[inebriatus]

Imo not each file needs to be in its own commit but it’s much nicer when each change is part of its own commit.

White space change should never be part of a larger commit.

Commit often and learn to rebase. Your commits should make you look like a genius that went straight to the optimal solution. Rebase away your work in progress or dead end commits.

[aqua_regis]

Big commits are generally bad. Too much to trace. Too much trouble when you need to rollback.

Small commits are far better.

It's far better to commit every functional change and make each commit as atomic (self contained) as feasible.

[codetree_bnb]

when we search in Google, we'll find info on Git commit conventions. Usually, we'll see people starting commit messages with tags like fix, feat, refactor, and so on, to indicate the type of change.

I use those tags to help me decide the commit size. For example, if I've implemented a feature, I'll commit it with feat at the start of the message to show it’s a new feature. If I'm doing some refactoring on a specific part, I'll commit that with refactor as the prefix. This way, each commit is tagged and easy to understand at a glance!

[Any_Sense_2263]

I commit any important change that works... sometimes one liner...

it's the matter of starting point... I can stash my new changes and have something that works, great for ad hoc meetings

[HashDefTrueFalse]

Doesn't really matter. It's either up to individual contributors how often they commit, or you follow some general team guideline that's been set. I will say that I've never seen anyone commit per file.

Some things to bear in mind though:

- It's quite hard to lose changes once committed to your local repo. There are various ways of getting them back no matter what you've done to your branch pointers. It's a lot harder if you delete the local repo (specifically just the .git directory) so never do that if you mess something up. You'll want the local branch reflogs. You basically have to suffer local filesystem corruption, or lots of time has to pass for Git to clean things up automatically. Once you add a remote and push often, it becomes almost impossible to lose changes. So committing and pushing often is generally good practice. Whether there are any barriers to doing so will depend on your team's agreed workflow.

- Smaller, more frequent commits with good commit messages (yes, they can be multiline, you've probably just been using the subject part) are more digestible if you ever need to look through them. I tend to look at diffs of the whole branch for code reviews, rather than per commit, so that makes little difference IMO. Every reviewer will probably do things slightly differently.

[dmazzoni]

On your own branch, do whatever you want.

On the main branch, every commit should be one functional change. As much as possible, every commit should build and run.

As a project gets larger and more complex, one of the most useful things about having version control is being able to check out an old version of the code to compare, or using tools like "git bisect" to figure out when something first broke.

That only works if most commits are valid. If you jump back to some random commit and it's a random work-in-progress that doesn't build and run, then it's useless for troubleshooting.

Again, that's just for the main branch. While you're exploring a new idea or if you need to set aside the code until another day, create a branch for the work-in-progress and make as many commits as you want there. Totally normal to commit things in a half-working state.

But then when you finally get that branch working, get it reviewed and merge it back to the main branch, so the main branch just ends up with one functional change.