1. Sure, if you're an expert, each command is useful. Practically, I commit only when it's ready (building, passes tests). So why would you commit without pushing (unless you're offline)?
2. I know what it does. I've read some manuals :) . The thing is
a. I'm not a VC (Version Control) expert, and most people aren't being paid to be VC experts.
They're paid to produce code.
Now, I (unlike a lot of people) don't mind spending some time learning my text editor (vi) which I use eight hours a day, but I'm not going to become an expert in a tool I use five times a day at most.
I just don't interact with it that often.
b. Good software is really meant to be gradual interaction. Take vi (which is infamous for being complicated) for example, to use vi, you need to know about 4 or 5 commands, each of which is a single letter or two letters at most, "i" to insert, "x" to delete, ":w" to write and ":q" to quit. Now you can use vi as a glorified notepad.
You need a more complicated workflow, you need to copy,paste, undo, fine. Learn each one as you need it.
And this is one of the more obtuse text-editing programs.
Honestly, if I used a text editor as often as I use git, I'd use nano or something.
If you commit whenever you complete a feature, or fix a bug, you'll quickly see the benefits. You can look back and see exactly why you made a change, or where you introduced a bug. And the best feature is being able to make a branch for dev (or each new feature you are adding), and be able to switch to master if there's a bug you need to fix.
Also, if you work with more than one person, committing early and often is invaluable.
Really, Git takes like an hour to learn. You could also just download tortoisegit if you really want to be lazy about it.
> I'm not a VC (Version Control) expert, and most people aren't being paid to be VC experts.
I agree that git could probably use some UI improvements, but to counterweight that - you're a paid professional, it's expected of you to learn the tools of the trade. It's like saying that carpenters are not being paid to know how to use saws and powerdrills.
You can simplify a tool only so much before it starts losing its utility.
--
People's refusal to sit down and spend literally half an hour learning to use something is astounding. Is that the "distraction culture" at work?
I commit often in scenarios where feature I'm working on is complicated and I've broken it down to smaller tasks. When I finish one task A and move on to B, I might end up in situation where A is not actually supporting B so I might need to refactor A . So when I finish A,B and C, refactoring for for A is not needed anymore and in this point, if I wouldn't have the history of modifications to A, I would need to rewrite it, or at least parts instead of just reverting.
And finally, I squash all commits to a single feature commit.
Two people have already described why the git process is so powerful. However, let's put some context to what you are saying. 'git add', 'git commit' and 'git push' take a grand total of 25 characters (including spaces) for three commands. If this is too much overhead and gets in the way of producing, I'd hate to see how much writing a switch statement gets in the way of producing.
> Practically, I commit only when it's ready (building, passes tests). So why would you commit without pushing (unless you're offline)?
I haven't set up a VCS server yet. I've fixed a security issue and haven't hit the embargo date yet. I'm doing exploratory coding (prototypes, refactorings, etc.) that may be discarded or reworked, even if it builds and passes tests right now. It passes all local tests but needs to be fuzz tested overnight before I'm satisfied enough to commit it upstream - but want to keep working in the meantime. I have more related changes to make before wanting to sic reviewers or the CI build process on my changes. I want to push my changes to a dev environment, but not a production environment just yet. I want to rebase to make my history look cleaner, but can't be bothered with doing so just yet.
I commit when it's not ready: I use WIP commits instead of stashes, and sometimes commit more often than I build. This has advantages: It can keep the individual diffs cleaner - an autoreformatting of a file to fix whitespace issues, and hand-implemented refactoring, should be separate commits for cleaner, more readable and reviewable diffs. This has drawbacks: In a centralized VCS, these will either get merged together into one messy commit (common), or they'll get blindly commited without (re)building for all permutations and occasionally break the build, or you'll slow everything down painstakingly testing the entire build after every minor permutation.
> but I'm not going to become an expert in a tool I use five times a day at most.
I'm no expert either. That said: In the interests of smaller, simpler, more reviewable changes - both for whoever might be doing a code review, and for myself if I mess up and want to figure out what I've done in the past few minutes to break something - I interact with my VCS much more frequently.
There are days I make 30 or so commits, and I likely diffed each commit multiple times before committing and/or submitting.
Aside from making it way easier to figure out what the hell it is that I've done, being able to finger a specific small changelist as having broken something has saved me tons of time I'd otherwise squander on false leads and disbelief. One of the nastiest heisenbugs I've had the misfortune to debug, I manually did the equivalent of a 'git bisect' on a perforce repository to track down the offending commit for. Totally innocuous change, totally to blame for a fruitless 2 week session of debugging in vain thanks to a buggy system API it used. So innocuous and seemingly unrelated, that I had to reproduce the issue in a simple test app to convince myself it was really the problem. I could've easily wasted another 2 weeks had the changelist been a little bit larger.
.
TL;DR: Smaller commits have saved me months of work, I figure. Committing without pushing lets me commit without shifting gears, encouraging smaller commits.
2. I know what it does. I've read some manuals :) . The thing is
a. I'm not a VC (Version Control) expert, and most people aren't being paid to be VC experts.
They're paid to produce code.
Now, I (unlike a lot of people) don't mind spending some time learning my text editor (vi) which I use eight hours a day, but I'm not going to become an expert in a tool I use five times a day at most.
I just don't interact with it that often.
b. Good software is really meant to be gradual interaction. Take vi (which is infamous for being complicated) for example, to use vi, you need to know about 4 or 5 commands, each of which is a single letter or two letters at most, "i" to insert, "x" to delete, ":w" to write and ":q" to quit. Now you can use vi as a glorified notepad.
You need a more complicated workflow, you need to copy,paste, undo, fine. Learn each one as you need it.
And this is one of the more obtuse text-editing programs.
Honestly, if I used a text editor as often as I use git, I'd use nano or something.