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).
this post was submitted on 26 Aug 2023
3 points (100.0% liked)
Transprogrammer
818 readers
1 users here now
A space for trans people who code
Matrix Space:
- #transprog:socki.moe
Rules:
- Don't be a meanie
- no *ism
- consider the feelings of somebody who might read what you say
- Don't shitpost
- Keep it wholesome
- Must be trans / programming related
founded 1 year ago
MODERATORS
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.
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!