>>The idea is commit snapshots of the whole project. Once set up right a simple
>>

>>RUN "git commit -a"
>>

>>is enough in most cases
>
>Eh no. There's a lot more to git than `commit`.
>
>Especially If you work in a distributed environment. Sure if all you want to do is commit locally that's fine. But if you're like me you actually use Git for diffing, code sharing (public and private), code forensics (ie. searching code for changes), and of course you need to push the changes upstream so they can be shared. There are Pull Requests and PR management etc. and IDEs (or even sites like GitHub) make all of this tremendously easier than using the Command Line. There's an entire eco system around Git commands.
>
>Yes you can use the CLI but the commands are non-intuitively named and often require even less obvious switches - it's one thing to remember 2 or 3 commands, but quite another to do this with a couple of dozen commands and switches. At least it is for me.
>
>Don't get me wrong - I'm happy that CLI functionality is there as I can use it to automate many tasks, but for day to day operations I have my Git tooling (I use SmartGit) open and frequently pick and choose commits (or discard) and there's no way I would do this as efficiently from the command line - just the typing alone even if I remmebered commands would take more effort than picking files and clicking a button. I almost never do a wholesale commit for example - almost always (especially with Fox) there are files that I don't mean to commit or need to discard for example.
>
>+++ Rick ---
>
Hi Rick
The good and bad of git is, that there is no really right or wrong. Only starting with a GUI without working through git pro first, is not my recommendation. But to many try this way. While a mighty tool, git is not VSS and has any odd-minded-idea somebody like Linus Torvalds could put into it.

We do not start a war about the high intuitive git syntax. List the content of a sub command -> show, list, -l or -v is just for starters. Everybody likes this. There are whole web sites makin fun out of it.

I do all of that you name, and in most cases commit single files - but this is more to the problem that I commit atomic changes. Mostly I merge --squeeze those crap to something meaningful if a task is done.

What I mean is, the day to day main work - commit forward - is, set up right (mostly .gitignore), nothing then the command above. It will simply only catch the file(s) changed. I do this down to extracted classes out of VCX.
For the .gitignore - I've set it up reverse, have a look at https://github.com/fdbozzo/foxbin2prg/blob/master/Documentacion/github/FoxBin2Prg_git.md#gitignore
And then the basic idea of git is to have snapshots of the whole project rather then single file checkin.

I'm not completely free of GUI - searching a commit on CLI is an useless pain. It's amazing how a simple tool like gitk that ships with git for windows can avoid a lot of diff.
Neat, odd, small simple. And all the info visible.

But then, after groking git, I feel awkward and limited in any GUI - and anything I see is limited to that GUI, or what the code monkey creating it let me know. What in many cases is not enough. Or even the wrong approach - I struggle with IDM's Ultraedit and Ultacompare. They simply act on f.. file based approach as if one would use VSS. I've talked them to have the merge compare without git support on, so I like it for difftool and mergetool (for mergtool it's not useable standalone, returncode 0 all the time, don't get me started). I have done beta testing for them, and the stuff I (with my limited knowlegde, I'm not a git guru) understand or even know was possible at all and they don't was no fun. I guess they still fail on branches open with git worktree.

Normally more then add, commit, switch, reset, checkout, push, pull, merge, mergetool in there most basic cases is not needed. I do a bit more complex, but that is mostly wrapped in some bash files, and git alias for two single liners to complex to remember. log, blame and diff, as I wrote above, I do mostly with gitk.
And don't tell me moving the mouse to a Button and click it is more difficult then git push. Changing the window to bash or GUI we must anyway.

And I bet that anything more complex will not be handled by a GUI to well. And then one must use CLI - and is lost without help.
So I prefer starting simple, and learn the use of that what I need step by step. One will have some delays in the work flow from time to time, but one will understand it. I'm not a JS developer and try to keep it that way. :) Over the years I've gathered a bit of understanding. It's not much harder then any other lang.
Or, let me say it so. VFP's way to search files is much more tricky. See Tamars problem lately.
;)

Lutz

Buy the way, github is a joke? Normally I use a privately hosted gitlab server. Github is for the VFPX stuff only. There I feel like a ballet dancer buried in glue.