Content
@
0 reply
0 recast
0 reaction
Thomas
@aviationdoctor.eth
How often am I supposed to commit and push to GitHub? I work mostly on solo projects, so I treat my repo mostly as a backup feature, i.e., I might commit once at the end of each day, and even then in the least descriptive manner (“fixed some stuff”). Should I be pushing every time I make one discrete update, which might be several times a day? I feel that this may be one of those late realizations in life like when you accidentally find out you haven’t been flossing and brushing your teeth in the correct order
8 replies
2 recasts
56 reactions
Darryl Yeo 🛠️
@darrylyeo
Lots of benefits to committing atomically and as often as possible – easier to migrate features to other branches by cherry-picking or rebasing, easier to rollback or revert specific features out of order, easier to track down where a bug might have been introduced. More work upfront but well worth it in my opinion.
2 replies
0 recast
16 reactions
Adam
@adam-
Feels subjective to the individual/ use case as opposed to a standard we should all be abiding by
1 reply
0 recast
2 reactions
huugo
@huugo.eth
Love this question… But wait, is there a “correct” order for brushing and flossing?
1 reply
0 recast
1 reaction
pugson
@pugson
you should commit often, push when it feels right
1 reply
0 recast
1 reaction
Nico
@nicom
So first, remember that committing is not pushing. Commits should ideally be done atomically to help you go back in history change by change. It's less a backup than organising the codebase. I have a lot of side projects that I leave untouched for months and I love to have commit messages to explain what I did, where I was at... Even if I work alone on them. It allows to be more multi project. Pushing is the backup phase. Do it once a day. Do not forget that your IDE probably also has a local history in addition to git. So you can rely on it for short refactoring or experiments. Finally, do not underestimate adding comments in the code directly, Todo, fixme, ... They will really help the WIP.
2 replies
0 recast
1 reaction
David Cann 🦁🍊🟪
@davidcann.eth
In the early stages of a solo project with big changes happening in many parts of a project, my experience is that rolling back via git is unlikely and tedious, so the rate of commits is not important. Once a project is more stable or involves multiple developers, then clean commits with discrete feature changes or bug fixes (and clear commit messages!) become useful and important.
0 reply
0 recast
4 reactions
Rafi
@rafi
If you build alone, it doesn't really matter that much. However, doing checkpoints on your work every couple of hours may help in internalizing changes to your codebase and learnings that come with it
0 reply
0 recast
3 reactions
Tempe.degen 🎩
@tempetechie.eth
- when you complete a feature - when you finish work for some time (e.g. at the end of the day, or even just for a lunch break), and you worry your hard drive will corrupt and you'll lose valuable work (aka for peace of mind)
0 reply
0 recast
1 reaction
