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. They go 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 computer-speak: because the developers couldn't agree, a program has branched into 2 versions, each missing features the other has. Git is more liberal with the term. In Git a branch doesn't go 2 ways, it goes one way. Branch is another word for "working copy". Every day of normal programing starts by typing the
A typical conversation: "Are you making normal progress?", "Sure am. I'm working on a branch.", "I hope you're documenting everything." "This is actually my 3rd branch of the day." "Good, good."
In English a repository is a central storage area. As a computer term it's the same. Computers have places that are areas, but aren't central or aren't storage, and as a consequence aren't named repositories. That may sound complex, but anyone who grew up using human language does it unconsciously. The Git team, on the other hand, decided that repository means "any copy of the project". Your actual repository is a repository, but so is the copy your intern made. There's no special word for the main repository.
Git repositories can be local or remote. You might think that distinguishes them by purpose. Nope. Whichever one you're using now, that's local. There's no such thing as a repository which simply is remote. I don't know why people enjoy these terms. If a command or whatever include the address of another repository, "remote" is redundant.
The term check-out applies to limited resources. For example, we check-out books because no one else can read them while you've got them. The book is out, and where it's out has been checked. Thus the term check-out. If no one needs to know whether you're using something, there's no check-out. Unless
you're Git. In Git you
checkout a branch to make it your working area. No one else is notified or prevented from "checking it out" themselves. A git check out is missing both things that make it a check-out. Sure, "select" would be a better term, but where's the fun in that?
When you check something out it feels like you need to get the most use of out it before it's due back. Checking a thing out revs you up. They were going to name the command weekend pass to the stud farm, which makes as much sense as check-out, but that was a little too exciting.
This also gives us stash. In any program when you switch working areas, you can save what you had, toss the changes, or sometimes you can leave it as is -- not saved, but there if you want to keep going. To do that last thing in Git you stash the changes. That's a good word -- a hasty temporary hiding spot. But does "leave it as it is" even need a special word?
Occasionally I'll think about a word and wonder if it means what I think it does. "commit" means point-of-no-return, right? Or in a computer "save these changes". In Git, "commit" is the second step out of three for a save. As in the common phrase "honey, I'm all the way in this relationship, but you're only mid-way, you're merely committed". Git calls certain objects commits. You bundle your changes into a commit, which you can then use to save.
That process also brings us abuse of the word "add". 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. Instead Git says add is the first step.
add tags files to be used in a
commit. Used in conversation: "I asked you to add eggs to the cart, where are they?", "I added them -- I picked out a carton that I would have taken during step 2".
Maybe I'm being hard on git here. add adds changes to the commit staging area. It's not as if they could have named the command stage. OK, they could have. 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. In "I'm the boss" mode you work on your repository and push your changes to everyone else. That's a good use of Push
If you're not the boss, or if you like a more detailed history, you instead use a pull. To be clear, you don't pull anything. The command to push your changes is named pull. Here's why: Git isn't about locking files on check-out, it's about resolving conflicts after they occur. When a minion pushes their changes it's a request. You're requesting the boss pull it, if the changes look good. So it's a pull-request, get it? But that's too long. It's shortened to simply "pull". Seriously. Most Git-users say they pull their changes back into the main project.s
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 save your work you add the changes, create a commit, and send it in a pull-request. Once you become comfortable with that, the aliens who named things in Git will nominate you as their ambassador. The job requirements mention you being "playfully spent" which will make total sense to you by then.