thomas

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

PhD in aviation ∩ climate science | Aviator, diver, Etherean, nexialist | Host of /diving /ethfinance /eth-staker /geopolitics /science /singapore /thomas

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.

/frontend dev・founder/decentralized data wrangler /blockhead・ritual.net・UI/UX abstractionist・DeFi/web3 builder・dropout・24・prev /dydx・x.com/darryl__yeo

Agree with Darryl. 

Small atomic units give you much more flexibility to deal with issues of change...in a sense, the number of commits itself is a form of additional state you build up and have at your disposal.

If you want a more coherent log history in your repo though, (ie. a single commit with a clear message describing a larger chunk of work) you can do that at the PR level...squashing all your atomic commits up into a single higher-order commit that is what is left on `main` when you merge. (if that makes sense).

🐵 ← 🙈🙉🙊 → /phil →  phil.cockfield.net, db.team →  
ƒ(🌳) →  🧫 /sys  ←  @cell <T>

Tip for sifting through changes to stage: use GitHub Desktop, or Cmd+Shift+P “Git: Stage Selected Ranges” in VSCode/Cursor.

Also, don’t let this upfront work stop you from simply committing! Commit something directionally correct first, then get used to rewriting history and performing “time heists” on your past self👇

Apply staged changes to most recent commit:

    git commit --amend

Or, make a new commit that is marked as “fixing up” a past commit:

    git commit --fixup <commit hash here>

(Or install `git absorb` to automatically find the relevant commit to fix up for you!)

    git absorb --base HEAD~20

Then finally, rearrange and squash the relevant commits together:

    git rebase -i --autosquash HEAD~20
    git push -f

(Replace `HEAD~20` with an upstream branch name or your own estimate of how many commits ago you need to time-travel back to!)

creating and destroying; built flying cars & autonomous vehicles, now building /faust, more here: /july, web: july.rocks

Speaking of which:

https://warpcast.com/darrylyeo/0xd27377f7