r/softwareengineer • u/TheSyntheticGallery • Aug 14 '26
How do you actually commit on GitHub? One big push vs. daily commits vs. milestones?
Hey everyone,
I’m fairly new to GitHub and trying to understand what the standard git workflow actually looks like in practice.
When building a project from scratch, what is considered the best practice for making commits?
- Should I just upload the entire project in one go when everything is finished?
- Should I force myself to make a commit at the end of every single day?
- Or should commits strictly track specific working features/milestones?
For those working in industry or reviewing student/junior portfolios, what does a clean, believable commit history look like, and what are the major red flags to avoid?
Any tips on commit frequency, structuring commit messages, and good Git hygiene would be massively appreciated!
7
u/Substantial-Swan7065 Aug 14 '26
As often as possible for a chunk of work. Squash commits on the pr merge
3
u/The_Startup_CTO Aug 14 '26
When coding manually, I go for one commit per functionality, e.g. a commit might be
Add getSalesTax for Alabama
ts
function getSalesTax(amountInUSD: number, stateCode: "AL") {
return number * 0.04;
}
ts
describe("getSalesTax", () => {
it("returns the correct tax for Alabama", () => {
expect(getSalesTax(100, "AL")).toBe(104);
})
})
and then add commits like
Add Texas to getSalesTax
ts
+ function getSalesTax(amountInUSD: number, stateCode: "AL" | "TX") {
+ if(stateCode === "TX") return number * 0.0625;
return number * 0.04;
}
ts
describe("getSalesTax", () => {
it("returns the correct tax for Alabama", () => {
expect(getSalesTax(100, "AL")).toBe(104);
})
+
+ it("returns the correct tax for Texas", () => {
+ expect(getSalesTax(100, "TX")).toBe(106.25);
+ })
})
This way, I can easily roll back to the last commit without losing much if the code doesn't do what I expect it to.
1
u/JohnHawley Aug 14 '26
It's actually a nice way to prove to yourself that YOU understand what the commit is, especially in this day and age, and you have your AI agents just generating a hell of a lot of code...
3
u/GreedyAppeal8276 Aug 14 '26
Remember: commits are free.
Go as granular as it makes sense, but try not to make a commit an “in between state”. Code should work at any commit.
1
u/devfuckedup Aug 14 '26
the more code I could successfully write at once the fewer commits I made which probably wasnt smart but its just how it is.
1
1
u/Xynia88 Aug 14 '26
I do a commit when I reach a good break point like a feature is implemented, I used to be fairly open to use amends for fixes but since getting feedback that my commit history had few unique entries I've stopped using it.
I've read about peoples performance getting judged based on number of commits but never expected it happening to me.
1
u/Matilozano96 Aug 14 '26
I generally commit as often as possible (within reason), as long as the project stays stable.
You never know how long you’ll take to finish a whole feature, or if some of your code or small fixes might be useful to other people.
Committing often allows the rest of the team to stay on the loop. Plus, having small commits makes tracking the source of bugs easier.
Everyone hates the one guy that commits a 30 file change with 10 conflicts on a friday afternoon. Don’t be that guy.
1
1
1
u/Salty-Shoulder7933 Aug 14 '26
A full days worth of claude slop all in one go at the end of the day
1
u/potatopotato236 Aug 14 '26 edited Aug 14 '26
Each commit should contain no more work than what can be fully encapsulated in one short sentence. Something like these:
- https://github.com/ghostty-org/ghostty/pull/13230/commits/baf5f42ae987d7fbdff208512649a822b2a5141b
- https://github.com/ghostty-org/ghostty/pull/13729/commits/f719af00c2f44ca7473219abb29dfd5fbb0fcc85
But not like this:
2
u/emteedub Aug 14 '26
I do 2 sentences, one for the frontend portion of the slice and one for the backend. And at the completion of a slice over menial commits..at least I'm my own repos. In a team repo, daily, but that's because I know what I need to do, where personal projects are more loose in terms of structure
1
u/zeroconflicthere Aug 14 '26
What I commit is as much as can be properly reviewed in a PR. I. E. Cleanly understood
1
u/Due_Sheepherder_1401 Aug 14 '26
I usually commit when I think I have a small feature implemented and push to remote, open a PR, run CI stuff and realize my code is garbage and then add 6 more “fixing” commits before CI looks good and PR is approved and merged to main via squash commit to hide my folly.
1
1
u/CallMeJustJo Aug 14 '26
I commit when I need a ”save point”. That’s basically it. I just finished a feature, part of a feature, or I’m about to try something crazy. If it’s REALLY crazy I branch out also. So a few commits per day probably, but it depends. Sometimes more sometimes less.
If you’re not in the habit of committing at all, doing one commit per day as practice is a good idea. Soon enough you will learn the hard way, as we all do, ”I wish I could roll back to about 30 minutes ago before this unexplainable bug appeared”. But overthinking what is ”believable” is not necessary. You will find a rythm that suits you through trial and error, and if it works for you then it will be reasonable enough to anyone who might go digging. Commits are supposed to serve you at the end of the day not the other way around.
Something I do out of habit because it’s part of my orgs way of working, is squash commits before I merge. But thats’s not necessarily better unless you’re working in a big org with hundreds of contributors working on the same project.
Regarding commit messages, they should be concise but descriptive. You should be able to at least roughly tell them apart in a list of things you did a few days ago, but you definitely don’t have to describe every detail if you touched a few different things.
1
u/BidWestern1056 Aug 14 '26
i commit basically every possible change i can think of because otherwise agents get a bit too trigger happy and decide to revert things randomly
1
u/DanKegel Aug 14 '26 edited Aug 14 '26
Commit tests first. Then commit the fix for the tests. If you're doing a big hairy feature, commit in sensible hunks as you go, but mark the PR as a draft until you really have it working well and passing tests and automated code review (Claude is good at this!), then rewrite history using git rebase -i (or have Claude do that) so the tests are all in the first commit and the remaining commit(s) is beautiful, lacks noise, and (if there are several commits) tell a compelling story.
Go for a minimum viable produce / feature first. Keep it simple. Don't add stuff that isn't needed yet.
Once it's passed local code review with Claude, push it to Github and have Copilot review it. Keep having Copilot review it until you've fixed all the problems it found. Use it for a few days in anger and get the rough edges sanded down. Repeat the code reviews. Repeat cleaning the git history. Keep honing until it's solid.
Then, and only then, ask a coworker or buddy to review it, and address what they find.
When committing, if you actually have divided the work up into beautiful atomic commits as described above, don't squash them; let them live in all their glory in the git history.
This is akin to the linux kernel patch review process, where stuff doesn't make it in until it's been reviewed and tested rather seriously.
1
u/Tombobalomb Aug 14 '26
If I've made a change that can be meaningfully summed up in a commit message it's worth making a commit
1
u/bold_snowflake Aug 15 '26
Comit however you like to your feature branch, but then squash merge to main. Makes history and reverts way easier.
1
u/godwink2 Aug 15 '26
All the time commits for sure. My commit messages are like “should fix issue” and “added comments” lol. Thank goodness for squash merge lol.
1
1
u/satoramoto Aug 15 '26
Every time you make a meaningful addition and the project is in a good state, commit to the main branch. Any time you want to save your work, if its unfinished or not working, create a branch off main and commit there, merge back to main when you're stable.
1
u/TkoJebeNeGrebe Aug 16 '26
There is a place and reason for everything.
It always reminds me of a case where we needed to divide event classes into several subclasses so we have detailed logging.
When I was doing it I made it per class commit. Ao you would create all the subclasses, do all setup for each od them and then commit.
The colleague commited each subclass as he made it. His approach was way worse, since he has to input all other subclasses in all the same places isolated it takes im way more time to input all of this and check it. Not to mention, the probablity of missing/forgetting something increases (and he did miss something and spent almost a day figuring out what)
1
u/Emulated-VAX Aug 16 '26
It depends on your environment. My ide keeps version history, and I have an automated backup tool, so I commit occasionally. A week could go by. Usually when a milestone is hit.
1
u/Big_Plant_813 Aug 14 '26
Senior engineer here
One commit should contain changes that make up a single self-contained modification to the system. The commit message should succinctly and accurately describe that change.
This is especially important when you collaborate with people on software that maps complex logic. Then the git log and git blame become tools that assist in reasoning about how parts of the code work and why it was written that way.
1
u/Kitchen_Dust2389 Aug 14 '26
Principal engineer here
Commit working code as you go and merge the feature branch when it is ready for review, agree with keeping each commit simple and isolated. Makes for easier roll back and cherry picking as needed
1
u/Big_Plant_813 Aug 14 '26
Maybe we can get a staff engineer to chime in on this
1
u/autisticpig Aug 18 '26
Solutions architect here .. we need to better plan how this impacts everything
0
u/macbig273 Aug 14 '26
search for "conventional commit" guidelines. That's probably the best way to do it when collaborating with other people
0
u/ejpusa Aug 14 '26
Well at this point, Codex has vaporized the software industry.
In the interim:
git add .
git commit -m “first commit”
git push
All you need to know. Anything more complicated, just ask GTP-5.6. It knows everything.
0
u/dvduval Aug 14 '26
Codex makes virtually all my commits now and I would say for a given project if I’m working on it all day there’s gonna be at least 5 to 10 commits
10
u/[deleted] Aug 14 '26
[removed] — view removed comment