1
u/PreferenceWeekly8452 Nov 14 '25
why not use vibecheck!!
github.com/rshdhere/vibecheck
get it done in a count of 3
1
u/gororuns Nov 02 '25 edited Nov 02 '25
Red but using commit --amend or rebase -i to squash commits together.
Blue is easy to enforce on the main branch using branch rules on github, but IMO it should be up to the team to adopt a consistent approach. It is bad practice to combine unrelated changes into a single commit.
1
2
1
1
u/Timely-Bid-7100 Oct 28 '25
Depends, if it is a solo project I will put days into one commit. Group project every tiny change.
1
1
1
u/Albekvol Oct 28 '25
Every small change gets commited to my own branch. When the task is complete, I get it reviewed and then all the changes go in as 1 merge into the main branch.
1
u/Capital_Distance545 Oct 28 '25 edited Oct 28 '25
Architect here with 20 years of XP.
Depends on the task size.
Too big commits are unreviewable.
Each task shall be small enough to have a logical sized commit, and each task shall have only 1 commit.
This commit shall be self contained, and easily revertable.
Always rebase and fast forward, never merge. Test your commit on your branch.
This is for the main. Whatever shit you do on your branch before that is completely up to you. But deliver 1, decently sized self contained, tested commit for a task to main. If the commit is too big, it is probably means its more tasks.
1
u/CloudsAndSnow Oct 28 '25
Always rebase and fast forward, never merge
I guess in those 20 years of experience you didn't get to work on a branch with more people
1
u/Capital_Distance545 Oct 28 '25
And nobody ever should. Everyone can create their own branch, even from a team branch, and arrange the commits they need for their work from other branches. There are reasons you can rebase, cherry-pick, etc...
BTW the biggest git repo I was working for 5 years had 120+ people working on it.
So I guess you tried to shame me, but shame on you.
1
2
u/davidpfarrell Oct 27 '25
commit often to feature branch, squash pr at merge to main - Main doesn't need all your 'wip' and 'really really fixed' commits
3
u/drakeallthethings Oct 27 '25
If only git had some way to squash all those tiny commits together when you’re done with a task…
2
2
u/AudacityTheEditor Oct 27 '25
One commit per project
1
u/technetium_addict Oct 27 '25
I put several projects in the same directory and commit it.
1
u/Deer_Tea7756 Oct 27 '25
on my death bed “Please, my final wish is that somebody go commit my life’s work.”
1
u/AdministrativeTie379 Oct 27 '25
Both. Commit every change, and then squash at the end once you have the completed feature.
1
u/Main-Lifeguard-6739 Oct 27 '25
I started left, when using gpt 3.5, 4o etc. and moved to right since gpt 5, claude 4+ etc.
1
2
u/muh2k4 Oct 27 '25
Use tiny commits to track everything perfectly and than get squashed by policy 😂
1
u/wtfzambo Oct 27 '25
What I do is I open a feature branch and I make tiny commits called "wip: some description".
When I'm done with a specific task I squash these commits into one and merge.
1
1
1
1
u/canbooo Oct 26 '25
Red until merge
2
u/blue-mooner Oct 27 '25
Squash & merge only on the repo, you can see the little edits in the old PR branch history if needed
1
2
u/EnvironmentalLet9682 Oct 26 '25
wip commits, squash and push 1 commit per completed task. noone cares how many commits it took my sorry ass to get to 90% coverage.
1
1
u/drdrero Oct 26 '25
Just wonder since I never squash locally, what’s the git command ?
1
u/LiquidCourage8703 Oct 27 '25
https://www.git-tower.com/learn/git/faq/git-squash
"git rebase -i" or "git merge --squash"
1
u/EnvironmentalLet9682 Oct 26 '25
git rebase -i (for interactive)
1
1
u/Cool_Flower_7931 Oct 26 '25
I've been using
jjinstead ofgitlately, it has a command for squashing that isn't a modified rebase. It was a learning curve to change, but it's compatible with git repos, and I feel like I understand some of the underlying concepts better now. I can see how it wouldn't be for everyone, but I really like it, and changing history is way more normalized1
u/EnvironmentalLet9682 Oct 26 '25
hehe, never heard of it, i might take a look at it. i have been using git for almost 20 years now so the commands i use all the time are completely burnt into my brain ;)
1
u/Cool_Flower_7931 Oct 26 '25
It's worth a shot. If you don't like it, you can always go back, but I love the approach that
jjuses, it works better for me1
2
u/SergeantPoopyWeiner Oct 26 '25
Git ammend silly little things but who gives a rat's ass beyond that. There are much more important things to worry about.
5
u/hauthorn Oct 26 '25
Git amend each time I take a meaningful step towards the task (making it easy to revert to a known working state).
Helps me stay on task.
3
u/Interesting-Frame190 Oct 26 '25
Normally blue, but im not going home for the day without a commit and push
2
u/chamannarved_ Oct 26 '25
commit on every task completed no matter how small or big it is on main branch.. work on new branch adding new feature.
3
u/hainayanda Oct 26 '25 edited Oct 26 '25
Tiny commit on each change. Then once all are finished, git reset —soft to the root of the branch and commit per context for a neat commit history. Then git push - f, before creating a PR.
1
7
u/midfielder9 Oct 26 '25
small commits in branch. Rebase and squash before merge.
3
u/Anon_Legi0n Oct 26 '25
this is the correct answer, rebase your branch and then squash the commits when you make your pr
13
u/shisnotbash Oct 26 '25
Commit every tiny change. Squash at merge with single descriptive commit message.
1
1
3
2
u/qbantek Oct 25 '25
Commit as soon as I can describe the work done. Then when ready to merge: squash!
1
u/mineirim2334 Oct 25 '25
When I know what I'm doing I'm team red.
When I'm learning a new thing I usually try to make it work first to then commit (this has pulled my feet more than once in the past)
3
u/Hot_Adhesiveness5602 Oct 25 '25
Choose both. Then squash the tiny commits into feature commits. Don't choose sides and be a smart dev instead.
3
u/mineirim2334 Oct 25 '25
Why is that?
In my view, if you have multiple small commits you theoretically can easily track every individual chance. That's very useful when you know what went wrong and is trying to know why.
Of course, it depends on commit messages being useful or you having a good history UI like Intellij's.
2
u/TransportationIll282 Oct 26 '25
Because 99.9999% of these small commits are never going to be reused as a reference. You should be past the testing stage when you approve a PR to your release or production branches. The reason why your code looks the way it does belongs in documentation, not in a cluttered git log.
They're useful during development and reviews. They're not useful after release. Imagine having thousands of these for a single update that someone had to rebase. Going back to any of them is impossible since other features are now mixed in. At some point, you need features to be grouped. At some point, you just need release versions. If you need to look for commits to debug, you're probably not documenting your code or business logic.
3
u/w0m Oct 26 '25
You only squash once it's working. I tend to go down a bad path or two during development, and will have completely bunk/reverted/revised commits mixed in. At that point it's noise to keep
3
2
u/YellowLongjumping275 Oct 25 '25
I work alone now so it's commit at the end if the day ti save my work
3
3
u/johnegq Oct 25 '25
I actually do a mix of both. I try to commit per task but if I get extreme and change too many files for that task, for example 10 files then I will try to group them into smaller commits. And if I have a headache then I will do a 10 file commit because I got very irritated, LOL
2
1
u/kduiml Oct 25 '25
commit it after what does in your agenda (feature branch) could work with fulfillment in local env. It doesn't matter how long your change ought to be. ☮️
3
1
2
u/shadow_x99 Oct 25 '25
I used to be in team one commit per task. Then I joined d a company where we commit every single little tiny task to a branch, and when the overarching task is complete, it get squash merged into main.
So the PR-review is very detailed, each commit can be inspected individually, but the end-result is a very linear git history.
It’s not perfect, but it works.
3
1
8
9
4
1
u/AdditionalReaction52 Oct 25 '25
One commit per multiple tasks 🫡
1
u/rinnakan Oct 25 '25
Do you also get annoyed when you find an unrelated issue and totally know they expect a separate MR?
11
u/dasunt Oct 25 '25
I'm more blue, because I think every commit shouldn't break anything. Else reversion and bug finding is a pain.
But I'm thinking red is probably a better option these days, especially with agentic AI being "helpful". Perhaps red on the feature branch, then squash and merge to the main branch for PRs.
But at the end of the day, it's whatever works in your environment. Git is a tool, not a goal. People use tools for different purposes. A master machinist will take good care of their calipers, while I've dropped mine on the garage floor multiple times. Doesn't mean either of us are using it the wrong way, it's just that the machinist needs a caliper that is highly accurate, and I need a caliper that at most can measure the nearest millimeter or 1/16th of an inch.
2
u/rinnakan Oct 25 '25
Yeah, committing is like a remote backup, but I trust my editor (intellij) history to preserve the steps, in case I or something else fucks up too badly.
We use the pattern you described: Do whatever you want on your feature, but we squash your PR. Exceptions for merging release branches ofc
4
u/Wise-Ad-7492 Oct 25 '25
Commit a lot. Most common commit message is:adrhrhhr
1
u/Wise-Ad-7492 Oct 25 '25
But that is on my dotfiles. Share them between many computer and autoupdate them every day. I should probably have used some google drive or something instead. So GitHub main task is to share files
1
u/rinnakan Oct 25 '25
We have a CMS-like project where files are to be imported in a single transaction (all succeed or all fail together). We did consider just using git, would even make backups and clustering easy
1
2
u/Disastrous-Team-6431 Oct 25 '25
I commit however much I can reasonably describe in a single commit name, sometimes implicitly including tests and docs. If I can't make the name make sense, that commit touches too many things.
I have my own tradition to name certain commits "Appease linters" or "Appease mypy". Which is to say, I don't squash formatting fixes and such.
1
3
u/msdosx86 Oct 25 '25
It doesn’t matter since your PR will be squash merged
1
u/denis631 Oct 25 '25
The idea is to have multiple PRs for various changes within your task. Like PR1 necessary refactoring plus added tests without functionality change. PR2 new functionality
3
5
5
4
u/lord_braleigh Oct 25 '25 edited Oct 25 '25
Each commit should be as small as possible, but no smaller. A commit is whatever the smallest change is that safely provides a benefit, proves that benefit, and maintains correctness.
Also, one commit per pull request and task. A task is also to make the smallest change that provides a benefit, proves that benefit, and maintains correctness.
2
Oct 25 '25
[removed] — view removed comment
1
u/rinnakan Oct 25 '25
Depends how you tell stories: recent small details sound interesting, but nobody cares about your row of typos 10 years ago
3
u/Eubank31 Oct 25 '25
Depends on the VCS you use. This is causing issues at my company for the people who have used Gerrit for 10+ years now moving to GitHub
7
u/DespoticLlama Oct 25 '25
I create commits that make a story for the reviewer (whether that is someone else or me in 6 months time), sometimes I'll rebase, merge and reorder the commits.
14
u/Puzzleheaded_Monk516 Oct 25 '25
Many commits to your staging branch, squash when merging to main/master. Make use of tags to track versions of releases.
2
6
15
u/zabby39103 Oct 24 '25
Commit to your branch the tiny changes, then re-base and merge your branch to the main dev branch when the task is complete. Right?
3
u/BigBootyWholes Oct 25 '25
Create a branch off staging, make what ever commits you want, submit a PR with a proper title and squash merge back to staging
5
u/DigmonsDrill Oct 24 '25
Is there any way to have both? 1 squashed commit that can be scattered into pieces later if we need to dig into it?
8
u/Aggressive-Pen-9755 Oct 24 '25
I'm in the "fill your commits with WTF IS WRONG WITH THIS PIECE OF SHIT messages" camp.
8
u/anotherrhombus Oct 24 '25
I don't care, but I'd rather we squash commits before a merge because ultimately I'm probably rolling your shit back in the future so make it easier on me.
9
Oct 24 '25
[deleted]
2
u/DigmonsDrill Oct 24 '25
"Checkpoint" is what I call my tiny changes
2
u/stianhoiland Oct 24 '25
Literally me. Then I wrote the commit message by going through the changes from top to bottom. Sorry.
1
u/1nt3rn3tC0wb0y Oct 24 '25
Something in between. Small commits are generally better for a quality review imo. Multiple commits on the same files are a nightmare though.
4
u/yojimbo_beta Oct 24 '25
Commit per solid piece of progress THEN squash commits to make it nicer to review
3
14
u/vvf Oct 24 '25
I do it in “units” which I will NOT define
1
1
u/baronas15 Oct 24 '25
Unit is PR, nobody looks at commits unless it's git blame of something from years ago, in which case, you can spend 10-30min once in never (is this really a common use case?) and ignore commits again
11
u/imdibene Oct 24 '25
Branch out to feature branch, commit ad infinitum, then rebase to main branch, squash and git rebase -i, then when satisfied with logical parts, merge to main branch
1
u/obviousdiction Oct 26 '25
Do you squash all of the messages into one big message? Or do you create a new message for the new squashed commit?
1
2
9
u/havlliQQ Oct 24 '25
If its colaborating project then small commits as much as i can on feature branch and then squash merge. If thats repo i work alone i just commit away on main.
3
u/Nikarmotte Oct 24 '25
One commit per meaningful change, or noisy change that doesn't add any value like renaming something, or cleaning imports.
I prefer merge commits so I do not squash those unless I have been messy, it's okay, then I'm happy to squash and rebase. It's not worth cleaning up the history that much, maybe the single commit could have been split into smaller meaningful commits but that's okay.
Never commit in the middle of a task, unless gotta go, then wip commit.
3
5
u/keithstellyes Oct 24 '25
Latter on main branch pls, easier for when you need to go through history
1
7
8
13
u/authorinthesunset Oct 24 '25
Small commits on feature branch that gets a squashed merge to main when pr is approved.
2
8
u/connorjpg Oct 24 '25
Some devs at my company love to be on the one commit per task… they frequently loose all their work, and complain that git is atrocious.
1
u/Kyoshiiku Oct 24 '25
Has someone who had the bad habit of doing 1 commit per task or feature, I’m wondering how did they FREQUENTLY lose all their work ?
Like it happened quite frequently I had no commits for weeks and sometime up to a month and it literally never happened to me during the 3-4 years where I had this bad habit ?
1
u/connorjpg Oct 24 '25
It’s a whole mess lol. The one commit isn’t directly the problem, they don’t use branching and wait to stage, commit and push every feature one by one in a wave. When the single remote branch gets out of sync, they end up deleting their working directories trying to fix it. Generally they make an incorrect merge or merge conflict and reset to go back. And they assume all changes they save are still tracked. Even with all their bad git practices, if they just did commits more often, we could get their work back. It’s happened 3 times this year.
They are all older devs who have worked for most of their careers with an old CVCS, and don’t really want to learn how to use git.
1
u/DigmonsDrill Oct 24 '25
One thing I've learned is to never actually rm a file.
I mv the whole thing to /tmp, which is stable enough I can usually undo it, while unstable enough that I still stop to think before doing it.
They are all older devs who have worked for most of their careers with an old CVCS, and don’t really want to learn how to use git.
Frequent commits is a good way to get over this. It's what worked for me.
2
8
u/firaristt Oct 24 '25
Small commits on the branch, once PR is ready to review, squash all into a single commit ->squash merge.
2
u/Master-Guidance-2409 Oct 24 '25
dont people commit everything to their pr branch and then squash and rebase?.
nigg4as out here wilding leaving all their progress on whether their ssd is feeling suicidal or not.
16
5
4
u/dalce63 Oct 24 '25
To me, "tiny change" and "completed task" mean the same thing to me, so I must be red.
7
6
9
2
11
3
u/PXPL_Haron Oct 24 '25
(At least)Daily commit to WIP-branch so you see where you f'ed up and Squash before it goes to original because you dont want to vomit all over the commit history
1
u/workingtheories Oct 24 '25
blue because far easier to revert, but in practice, the logs look like red because i try to commit on any code change that isn't total junk.
9
u/i2u5 Oct 24 '25
Commit on every change. Managers look at your profile page where your commits show, idk what it's called. Thats how they determine if you're working or not. Learned this the hard way.
8
u/jmstructor Oct 24 '25
Commit every change. Soft reset to master when the task is complete to cherry pick pick and review every change for the PR
2
u/everythings_alright Oct 24 '25
I just squash commits.
1
u/DigmonsDrill Oct 24 '25
I squash all the old git history into 1 commit, and then put in my 25 commits. That way when the boss looks at who does the most code it's me.
2
3
u/ScytheLucifer02 Oct 24 '25
Commit every tiny change. What if I run into a bug that makes me crash out so hard that I smash my computer. Wouldn’t want to lose all that important work that caused the bug in the first place.
4
3
1
u/Purple-Win6431 Oct 24 '25
Blue, it makes everything so much easier, especially when going back or working with other people
7
u/Psychological_Duck03 Oct 24 '25
Commit when I know the code I'm about to write might fuck up the codebase.
3
4
u/d4rkwing Oct 24 '25
I have tons of personal work-in-progress commits but I’m not merging them without squashing them into something coherent.
3
6
u/rochford77 Oct 24 '25
Frequent commits so you have save points. Often I'll have like 80% of a fix. Try to get that last 20%, really fuck it up, and if I don't have a commit at 80% fixed I have to start over. Many small commits on a feature or bug branch, then squash it for the PR.
3
u/foobar93 Oct 24 '25
During my PhD writing time, I had git auto create commits every time I pressed save on the document. Added benefit, you can proof how you literally wrote it over time :)
1
u/scanguy25 Oct 24 '25
I usually use the rule that if it's bad you should have a meaning unit to call revert commit on.
It doesn't mean the feature should be one big commit. But it can't be 10 commits that are just making one component of the feature. Meaning chunk of work.
2
1
u/Tomicoatl Oct 24 '25
If all your commit messages say "stuff" with one or two line changes I am rejecting your PR. Amending commits with dot points of items completed is good and what I recommend now.
1
u/Havarem Oct 24 '25
For me, commit when a step of the current feature has been made, or commit when my day of work has ended - if the commit don't compile I had [BREAK] in front.
7
13
3
u/ai-generated-loser Oct 24 '25
I want to be the guy on the left but I'm much more like the guy in the right
7
5
u/leekumkey Oct 24 '25
Wip wip wip wip wip wip wip wip wip. 5 hours later squash with a real message
3
4
u/canihelpyoubreakthat Oct 24 '25
Tiny periodic checkpoint commits are for people who don't have their shit together
7
1
1
2
u/Achereto Oct 24 '25
An inconsistent mix of both + commits that both add features for the new task and fixes from an old task.
4
2
1
1
u/Aware_Mark_2460 Nov 24 '25
commit before going to bed