You don't need to know this, by the way. You can totally just think of git as simply storing a copy of your entire repo every time you make a commit. This is one part of git that actually is a good abstraction.
Of course it is fun to know this but it won't help you understand git really, and please don't tell people who are just learning git. Just say git makes a copy of the whole project every time you commit.
I feel like git culture is one of the worst about these sorts of things. I've run into people that think you're a loser if you don't use it from the command line, but my commits using a GUI client are much cleaner and I seem to have much less trouble than they do.
I use command line for pull/push/new branch, VSCode for commits and Tortoise for archeology and merges. I just use whatever seems easiest for the task.
I'm the "git guy" in every job I've had. I never use the CLI! I use magit which is probably the very best git UI there is. A GUI is simply the best thing when you are in the process of building state. CLI is great for functional type stuff (ie. I type a command providing both input and output but is completely stateless). Building commits is one such example of working with state. Most CLI users I know just add everything every time.
I’m a non-coder and use git for versioning text files for my fiction writing. I don’t have any sort of deep understanding of git, but I’m pretty comfortable at the command line for commits, pushes, pulls, etc. I must admit I’ve started liking the GitHub gui app lately, though.
I'm certainly skeptical of folks that use Git GUIs. It has been my experience that the folks that I've worked with who only use Git from the GUI only know the absolute minimal subset of the tool to allow them to get code/changes into the CI system. As soon as something happens outside of that comfort zone, things go haywire. Adding insult to injury, many of the Git GUIs that I've seen people work with don't use "standard" terminology, or they combine/conflate multiple actions (I'm looking at you, VS Code). This makes it difficult to help when things go awry, or when someone's having difficulty understanding how to work in the team's established workflow.
Ultimately, I don't care what tools people use if they produce quality work and can integrate with the team without creating additional friction. There's nothing that says that a good GUI can't exist, or even be more productive than the CLI in some cases. I have had enough experience of GUIs causing problems, however, to make me nervous when I hear one is being used by a team member. It's often followed by something like: "I ran into a problem with Git, so I just deleted the repository and cloned it again."
Perhaps it's time for me to start looking at the available GUIs again, so that I can make a recommendation for a solid one when someone doesn't want to use the command line. In the end, though, one still needs to understand Git's behavior, to some degree, to be productive and avoid creating situations which take the team's focus away from our goals. I don't know that any GUI is going to help junior developers with that.
I use magit. You want a UI that allows you to easily see the changes in your worktree and add those line by line to the index, if necessary. Of course, you also want it to be easy to add whole files or hunks too, as always going line by line would be insane.
A good commit means a good version. That's what we're doing after all: version control. Every commit you produce should be a valid standalone version of the software. Commits can build on each other, e.g. you can add feature a then subsequently add feature b that depends on feature a, but a maintainer should always be able to only take feature a, there shouldn't be bits of feature b in there, and there shouldn't be fixes for feature a in feature b's commit.
With practice you can learn to make rough commits first then clean them up into proper commits later. For example, there are "end of day" commits and there are fixup commits. Those are both valid uses of git, but you shouldn't be exposing those to your team. You need to rebase them before sending them. A good git user will sow the seeds for a smooth rebase early.
That's not really a CLI, though, it's a really basic rudimentary text UI. Might as well spend the effort to learn it learning enough Emacs to use Magit. Can it even do line by line effectively? What about unstaging stuff you added accidentally? It's not a patch on Magit or even any semi-decent GUI.
Heh fair enough. For me, it comes with the advantages of the CLI that I care about (primarily: easily accessible with the keyboard, and launching without delay) without having to adopt a different editor.
I don't need line-by-line usually (but it can technically do it if needed), but undoing accidental adds is indeed a bit of a pain.
Eh? Emacs is the complete opposite of an elitist culture. The entire point of Emacs and free software in general is to destroy the elite (developers) and put the users (me) in control.
I want to understand git. But by that I mean using it. I don't need to know about the internals for that; I need to know common approaches to typical merge problems (where all of a sudden git loses a lot of its elegance).
I found out that GPT-4 is pretty good at helping me find/format git commands and solve git issues. These are usually short responses, repeated in many places on the web, and easy to memorise for the LLM. GPT is really a game changer related to git anxiety.
I have been thinking about this. Why no record all keystrokes. Then checkpoint where you are whenever you desire. These days AI could describe any arbitrary span of code changes.
That was Google Wave, it stored everything as an "operational transform". The presentation they used when showing it off to the world was brain damaged, they insisted as showing it off as a ton of separate blocks, instead of one continuous document, which gave people the wrong impression of it, and tanked it.
In a similar way, the impression that Git stores deltas, got stuck in my head somehow at the beginning and made it an opaque mystery for me.
It was only years later, when I somehow I managed to learn the truth, that Git stores full snapshots, and except for compression in extreme cases to save storage, it doesn't do anything with deltas (except fake them to show diffs)
It's not quite "all keystrokes", but git-wip is meant to add a commit every time you save a file: https://github.com/bartman/git-wip I've been using this (via magit-wip) for a while now and it stays out of the way. I've never needed to use it, though. I'm probably too careful now having been trained in a world without git-wip.
Of course it is fun to know this but it won't help you understand git really, and please don't tell people who are just learning git. Just say git makes a copy of the whole project every time you commit.