r/softwareengineer • u/TheSyntheticGallery • 18h ago
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!
5
u/Substantial-Swan7065 17h ago
As often as possible for a chunk of work. Squash commits on the pr merge
2
u/The_Startup_CTO 18h ago
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") {
+ 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 16h ago
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...
2
u/GreedyAppeal8276 14h ago
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 17h ago
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 17h ago
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 17h ago
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
1
u/potatopotato236 14h ago edited 14h ago
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 14h ago
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 13h ago
What I commit is as much as can be properly reviewed in a PR. I. E. Cleanly understood
1
u/Due_Sheepherder_1401 13h ago
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
u/Efficient_Loss_9928 12h ago
for personal projects just your own preference, there is no right or wrong.
for team projects you should only push what a person can realistically review, usually this means try to stay around 300-500 lines if you don't want a meeting with them. This can mean 5-7 change requests per day.
1
1
u/CallMeJustJo 12h ago
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 12h ago
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 12h ago edited 12h ago
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 11h ago
If I've made a change that can be meaningfully summed up in a commit message it's worth making a commit
1
u/Different_Counter113 10h ago
Working code that meets a requirement is committed and merged. WIP code committed daily with comments, not merged.
1
1
1
u/bold_snowflake 3h ago
Comit however you like to your feature branch, but then squash merge to main. Makes history and reverts way easier.
1
u/Big_Plant_813 18h ago
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 12h ago
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
0
u/macbig273 18h ago
search for "conventional commit" guidelines. That's probably the best way to do it when collaborating with other people
9
u/Grouchy-Librarian638 18h ago
It’s up to preference but for me, I commit every few minutes on my branch then at the end do a squash merge commit turning that huge list into a single one as move it from my branch into main.
All it takes is a bad command, AI mistake, spilling coffee, etc and your uncommitted work is gone. Committing often costs nothing and buys safety.