I barely know anything about Git, but I’m about to get trained in on more.

So I’m checkpointing what I think I do know at this point, in an “explain it like I’m five” fashion.

“OMG, you have it all wrong!” comments welcome.

(“OMG, that’s technically correct but painfully oversimplified” comments maybe less necessary at this very moment.) 😃

Git = paradigm for version control + software implementing the paradigm

Git refers to more than just a program running on a computer. It also refers to:

Protocols: How “Git” software manages data on the computer it’s running on
Protocols: How “Git” software should interact with other computers running “Git” software

Git (the software) spies on folders on the computer it runs on

But Git also does just refer to a program running on a particular computer.

Given information that a certain folder structure is designated as a “Git repository” on that machine, “Git” will spy on that folder, watching for changes to its contents.

Spy on a folder

To designate a folder a “respository,” you “initialize” that folder.

git init ...

Show changes made

You can ask your local machine’s copy of Git, “Hey, what file changes have I made lately?”

git diff ...

Clump changes logically

You can say, “Okay, great, I see that you’re aware of changes I made to files A, B, C, D, & E on this computer. Please clump (“stage”) the changes to files B, D, & E together as a unit that I can checkpoint.”

git add ...

git patch ...

Officially log a change clump

Then you say, “That clump looks good – I’ll add a comment and officially set it aside in this computer’s changelog (“commit” it) as a checkpoint.”

git commit ...

Fix a log comment

If you misspelled a comment, you can tweak it if you haven’t done anything important yet (like send a copy of that comment out over the internet).

git commit --amend ...

Roll back the log

You can, I believe, tell Git software running on your computer: “You know what? That last checkpoint? Nevermind, it wasn’t so important. Please remove it from the logs. But don’t change any files on my computer. I’m just not actually ready to have officially told the changelog that I changed files B, D, & E.”

(That said, I don’t know how.)

Roll back your file contents

You can also, I believe, use Git software running on your computer to say, “Wow, you know those changes I made to files B, D, & E that I added to the changelog? And the changes I made to files A & C that you’ve noticed but that I haven’t yet asked you to add to the changelog? Can you help me wipe out all those changes, to files A, B, C, D, & E, reverting the contents of those 5 files on my computer to the contents they had last time I checkpointed them, before today’s work?”

(That said, I don’t know how.)

Reflections

And that’s … the big ones … when it comes to things that you do purely with respect to tracking file changes on your local computer. I think.

Note that you make the changes to files A, B, C, D, & E through ordinary means. (Unless you're using Git to change them by "rolling back" your file contents, or by overwriting them from another computer also running Git.) You edit pictures in a graphics editor. You rename folders on disk as you usually would. You edit code in your favorite text editor or IDE.

Git is just the spyware/secretary that you can occasionally talk to and say, “Oh, hey, those changes were important. Jot that down for me, please.”

Git (the software) helps you talk to other computers running Git

Okay, actually, Git is one more thing on your local computer:

It provides commands that make it easy to talk to “Git” running on other computers that have set themselves up to offer “server” functionality.

You pretty much always interact with your own computer’s Git program to talk to the Git program running on another computer.

You’re not going to command a remote Git server, “Do ABC!” with curl or Postman. You’re going to do it by writing some command on your CLI that starts with the word “ git.”

Note: If you can SSH into the remote computer’s command line, of course you can more directly interact with its running “Git” program because that faraway computer now is effectively a “local computer” of yours.

That’s approximately what I did with my blog for the first few months. GitHub.com offers web-browser-based creation, editing, and deletion of files on their servers. Saving a file with the web editor automatically performs a corresponding git add and a git commit to track your changes. I didn’t actually bother to set up a local-computer equivalent of the repository hosting my blog until I:

realized it was stupid to go without backup
needed to rename/move files, which was easier on my local PC than in GitHub.com’s web interface

Just because you can directly edit files on a remote computer and use its local “Git” to stage+commit changes to its changelog, though, doesn’t mean that’s how you should interact with a remote computer’s copy of “Git” software. So let’s not mention this approach again.

Working with “remote” repositories (through your own computer’s Git program)

Saying which “remote repository” you want to work with

When dealing with a remote server that also runs Git, one of the first things you’ll do is tell your local computer’s copy of Git that a given “repository” on your computer has some sort of meaningful relationship to a given “repository” on a remote server.

git remote add ...

Specifying “remote” and grabbing its contents

Alternatively, instead of git init-ing a folder and get remote add-ing the remote repository and git fetch-ing + get merge-ing or git pull-ing the remote repository’s contents to your local hard drive, you can just run this one command, specifying what remote repository you mean, from the folder that you want to “init” and fill all in one fell swoop:

git clone ...

Updating the “remote”

If you have credentials in the remote server’s copy of git, you can take the file-contents and comments from “checkpoints” in your local “repository” and “push” them over to the equivalent filestore and checkpoint-history in the related “remote repository.”

git push ...

Problems updating the “remote”

Of course, the remote repository might complain that the changes you’re pushing seem pretty off-base from the file contents and checkpoint-history it’s already aware of. It might refuse to let you “push” your changes to its repository without fixing up those conflicts.

You can read more about that here.

The likelihood of you running into that problem depends a lot on:

How many people, on how many different machines, with how many different “repositories related to the remote one,” have “push” authorization to the “repository” on the remote server

Note: the answer to that may be “pretty much none.” Often times, extremely important server-hosted Git repositories refuse to be “pushed” to and only incorporate changes to their codebase+changelog by “pulling” code from other server-hosted Git repositories in reaction to “pull requests.” For example, to contribute a fix to Linux’s kernel’s official repository, you’d set up your own server-enabled remote repository (e.g. your own GitHub.com-hosted repository) and put in a “pull request” with the Linux folks. If one of them liked your work, they would “pull” your changes from the server you set up and incorporate your changes into the official repository.

I haven’t yet had a “push” command rejected by a remote repository.

But that’s because so far, I’ve only worked with three simple repositories, both of which I had sole control over:

My blog, which is a single remote-local pair. A real, live website’s readability depends upon the quality of the GitHub.com-hosted version of the repository, so I consider it my “source of truth” and do everything I can to keep my local-computer’s repository in perfect sync with it. I always always do a get fetch --all and a git reset --hard origin/master before making any changes to my blog’s files on my local computer, in case I forgot that I’d been modifying things through GitHub.com’s web interface.
My “cloud backup” of “what code changes I’ve been making to a Salesforce org.” We’re not on SFDX for that org, so the “org” is the “source of truth,” and I’m just periodically downloading copies of its codebase to a Git-tracked folder on my computer, “adding”/”staging” all the changes, “committing” them with a message describing any changes I find (e.g. “I just edited a trigger” or “Misc. sync.”), and doing a git push to my GitHub.com repository so that my IT department can easily replace my computer without me losing my entire change history of what kind of code is in Salesforce.
A Heroku app that scrapes Commit Strip’s RSS feed and lets me read equivalent comics in French & English side-by-side. Like my blog, this is “production code” running a “real web site.” However, like my “Salesforce backup” repository, I’ve never done anything but push code straight to it from a single computer. No complexity with multiple players, editing from multiple computers, etc.

More about working with “remote” repositories

I … don’t know.

I’m about to find out, I think, between training in and studying up.

I don’t know enough about git fetch... and git pull... and git merge... yet to explain those “to a five-year-old,” despite having used fetch and pull, so they’re not in scope for this post.

I’ve never done a “checkout” process, but will soon, so hopefully I can add that in the near future.

Since Git is typically used to deal with the complexities of version control across multiple computers, all things related to “interacting with remote repositories” are definitely what I presume to be the contents of most Git documentation on the internet.

That’s all, folks

More to come as I train up on Git and start using it as recommended by the colleague training me in.

Perhaps I will also play around with editing my blog as if it were a web-based production application, needing multiple contributors, feature branches, etc.

(That’s more of an … ahem … reminder to myself than content for you, dear reader!)

Additional Resources

3 podcast episodes I've been listening to, and found helpful, as I learn more about proper ways of using Git in a team:

Trunk Based Development vs Gitflow - The Rabbit Hole by Stride Consulting, episode 30
Git Tips, Tricks and Workflows - Full Stack Radio, episode 41
Comparing Git Workflows - Coding Blocks, episode 90

Git brain dump