I am currently working on a small project, and I am working on getting it functional, but I question when exactly should I make commits. I usually just do it when I am done with working on it, but I know in practical projects often times commits are for one specific thing but given the project does not even work yet what exactly do I do.
I feel like this is very subjective, but I usually commit whenever a) I have to edit only one thing in a certain file. If I am reasonably sure that I’ll only change this one thing in a file, I’ll commit b) I feel like what I have just done works, and it is worth writing an explanatory commit comment for: This could be whenever I add or modify a helper function, when I make a new struct, fix a bug, refactor something, etc. c) I am done with it entirely :3
I hope this helps at least a little!
Hardware can fail randomly at any time. I would commit and push to a private repo as frequently as you can. You can always squash the commits later when it’s complete. Definitely worth committing whenever you complete a feature, or before you remove any code (change of design, you may change your mind and want the code again).
For my team, we create branches off of dev to start working on a specific feature. It’s really up to the dev how often they commit to that branch but I recommend often to prevent losing any work. Once the feature is done we merge the branch to dev and roll all of the commits into one so looking at the history on dev, each commit represents 1 feature.
for me at this moment I don’t think branches are super relevant to me at the moment since the project does not yet function. I feel like it will function by next commit. also one question I have about dev branches is that how is it that I can compile and use the dev branch on some projects, like how do they work on code that is not yet functional and would break compiling the software until it is completed.
Oh yeah so our project is well established so different situation.
The feature branches are small complete pieces and they shouldn’t be breaking dev.
If this is a personal project, just commit whenever you want. At least when you’re finished working so you don’t lose your work.
Commit as often as you need or want and push into development branches. They are your checkpoints if you mess up, you experiment with things or you finish working on it for the moment. Just write commit messages that are useful for you to help you find your way back. Once the feature is done rebase everything into a single properly written commit and merge it with your main or feature branch.
In my experience that’s as good as you can get it to work for you without stressing about commits at all really.
I believe that best practices are to commit locally whenever you want (generally any time you don’t want to lose what you’ve done so far) but then do an interactive rebase to make your commits more coherent and more encapsulated before you make a pull request to get them merged into the branch on origin
I do it when I’m afraid of losing what I’ve done so far.
But that would only apply if you are the only one working in the branch or if you can do shelvesets. Which should be the case lol.
Do atomic commits and get really good at interactive rebasing. I find it let’s me try various small efforts, including refactors, and still keep a relatively sane commit history.
At your stage I usually try to avoid committing code that doesn’t compile/has syntax errors etc.
Later on I try to make sure that I can go to any commit in the history, and have a program that runs. For example, I don’t want to knowingly add code related to one feature that crashed the entire application just in case I need to go back later. But it’s up to you to decide how unfinished the state of the feature/program is allowed to be when you commit.
And if it’s a side project that only you will work on, you might also just say screw it, even if it catches on and other people will look at your code, they probably won’t care that much about how organized the early work was :)
