Git is an interesting program for two reasons. One is how it got people to think it's cool. It's a source control program, which is the most boring thing ever. It keeps records of changes, allows undo's, and -- this is the most exiting part -- alerts you when 2 people change the same thing at the same time. Wowie! The other interesting thing is the terms it uses. They're the worst. They're worse than the worst; from "no human would use that word in that way" to "we tested every word in the dictionary, then accidentally used the results backwards".
If Git became popular despite names this horrible, it must be really good!
In English, a branch is when something splits. It's the same in a program: the programmers couldn't agree, they each did it there way so the program now has 2 versions. Each is good at different things and there's no obvious way to re-unite them into one "good at everything" version; the code has "branched". Git is more liberal with the term. It boldly asks "what if a tree is just one long trunk, but the amount it grows every day counts as a branch?" Git-user think constant progress is actually many, many small branches, end-to-end. Put another way, a Git branch is merely a "working copy". A day of normal programing using Git starts by typing the
branch command. After doing one thing on your to-do list, type "branch" again to get your working copy for the next thing.
When a normal person would say they've gotten 3 fixes or improvements done, a Git user says they've completed 3 branches.
In English a repository is a central storage area. As a computer term it's the same thing. Having a word for such a specific type of place may sound complex, but anyone who grew up using a human language can understand it. The Git team, on the other hand, does not. They decided that repository means "any copy of the project". The main version is a repository, but so is your copy, and so is the sample copy an intern made. It's all just repositories. If you feel like having informal rules about which Git repository is the, ummmm, real repository, that's your business -- Git kindly allows you to make up your own name for that.
Git repositories can be local or remote. You might be thinking "aha! Now we're getting somewhere. That's how you can tell which is the main one!". But you'd be wrong. Whichever one you're currently using is local. Switch to a different copy of the project and now that one's local. The only purpose for remote/local is for describing Git commands. Git-users need a special word for "the copy of the project you're logged into" and another for "some other copy, who's name you wrote on the command line". It's easy. To trade sandwiches with a Git-user, ask to exchange their local sandwich for your remote one.
In English, the term check-out applies things one person can use at a time. When you check-out a book, no one else can read it. It's out. But you don't just take it -- you tell the library that it's with you -- that's the checking part. In Git it's pretty much the opposite. In Git you
checkout a branch, which becomes your working area. So a Git checkout makes it so you can share -- anyone else can "check out" their own branch of the same code you're working on.
This probably comes from older source control programs. In them you really check-out part of the program -- no one else is allowed to work on it until you're done (obviously they could, but not if they follow procedure and attempt to check it out for themselves). Git flips this. It's a immutalbe face that several people working on the same code at once will probably cause a conflict. But instead of preventing that, Git flags it and asks a manager to resolve problems.
In a typical tabbed editor every open tab is allowed to have unsaved changed. In other words, switching tabs doesn't bring up the "you have unsaved changes. Save or Discard?" notice. What's the technical term for "changes you haven't decided whether to save yet?" We never really needed one. Which is why Git calls it a stash. That's actually a decent word -- a hasty temporary hiding spot -- despite us not needing one. Now, to be fair, a typical tabbed editor won't allow you to quit and keep your "not yet saved" changes, Git will, so the word is nore useful: "you have unsaved changes: save, discard, or stash?"
Git just plain gaslights us on the word "commit". It means a point-of-no-return, right? Or at least a hard-to-undo step in a direction. In a computer commit often goes with "commit changes" which means to save it. The old version is gone -- you're commited to the new one.
In Git, "commit" is at least related to saving. It's the second step out of three for a save. It's also a noun. To save, you bundle up the changes you want into a Commit object. Latger on, you can use your commit to actually save. Suppose a Git-user tells you "honey, I'm really commited to this relationship". That means they've made a list of things like "tell my parents about you", "delete dating Apps", and so on. They haven't actually done any of them. But they've created the commit.
Everything in a version control system is about adding to the project, or changing, or deleting; but mostly adding. If you're going to name a command add you'd want to pick something that's the most add-y. Weeelll, in Git add is friends with commit, coming just before it. It doesn't actually add things to the commit object, but
add tags files to be used in the
commit command to create the object. So while technically Git's
add doesn't add anything anywhere, it's a small but important step in the process of actually adding. Just be careful when asking a Git user to, say, add two tomatoes. To them it means to mentally select two tomatoes, and nothing more.
Maybe I'm being hard on git here. It's not as if they could have named the command stage. OK, they could have, and that would have made more sense. But this late in the game a git command that did what it said would confuse everyone.
Git allows several set-ups, each with a different way of saving changes. The simplest is "my code is the boss". You work on your repository and push your changes to everyone else. This is a rare case where Git uses a term in the acceptable computer and human way. But they make up for it.
If you're not the boss, you instead use a
pull to save changes. Now let's review: pushing makes things go away from you, while pulling makes them get closer. Sending out our changes tp the master copy should be called pushing them. But it's a pull by Git's logic. In Git someone needs to examine your changes and approve them. That's part of the backwards "don't prevent overlapping work on code, instead merely flag it afterwards". So when you push your changes you're actually requesting that the decision-maker approve and then pull it into the master copy. So sending yhour changes is a pull-request, get it? But that's too long to say. It's shortened to simply "pull". Seriously, Git-users pull their changes out the door, over to the main project.
That all sounds complicated, but it's easy. To do some programming you start with your repository which isn't a repository, make a branch which isn't a branch, then check it out, which doesn't check it out. To get your work into the main project you add the changes, which adds nothing, create a commit, and push it by using the pull command. Once you become comfortable with that, the aliens who named things in Git will nominate you as their ambassador in a "Last starfighter" situation. Git will go away, having served its purpose.