This is an introduction to git. Frankly, git can be confusing. Relevant XKCD (Be sure to check the "mouseover.)
I think there are at least four reasons for CSC and ACT students to learn git.
- It is a skill employers like to see.
- It makes development easier.
- Students often comment out large blocks of code. Eventually there are more comments than code, and development has to take place in a sea of dead code. Instead, do a commit and then delete the code; you can always go back in the git repository and recover it.
- Multiple copies of source code files get saved. An hour after they are saved, you don't remember why you save that code, or how it is different than the current version. Or how it is different than the 8 other versions you hae saved. Do a git. Then change the code if you need to
- You might want to take a different approach. With git, you just create a branch, and try the new idea on that branch. If the new technique doesn't pan out, just abandon the branch. If it does work, then merge it with the master.
- It protects against computer crashes. Computer crashes are the high-tech version of "The dog ate my homework." Sometimes it is really the reason homework is late. If you have a remote repository and keep it updated, then you can just clone the remote and keep going
- On a group project you can document who did what. You can also incorporate all the documents in one place. Git repositories can hold more than just source code.
Start off small and build up to more complex operations.
- Start with individual projects that you are developing on an individual computer.
- Develop a project on one computer.
- Make commits at milestones and at the end of your work session.
- Push your project to the remote repository as you go along.
- Don't worry about bringing your code back down unless things go wrong.
- If you need to roll back to a previous commit or if your computer crashes, then figure out the command to recover your files.
- Develop some projects on two different computer systems. Don't use a USB drive to move it!
- Just move the project to a new system by cloning it
- Actively develop on both computers, and move the code back and forth between computers using git
- At some point you will forget to do a push before changing devices. Then you will have an opportunity to learn to merge a project
- Work on a project with one other student who has used git. Or at least one who is not afraid of git.
- At first, try to divide up the work so you are not editing the same files. Get comfortalbe with merging the project
- Eventually try merging a single file you have both worked on independently.
Before GIT there were a variety of "Version Control Systems" (VCS). In fact, there are still a variety of VCS systems available.
Before GIT, the Linux kernel development team used a commercial VCS system. There were problems with the system they were using. It also seemed kind of inappropriate for the flagship of all opensource products to be developed using a proprietary VCS.
In 2005 Linux Torvalds developed the git protocol.
Git was developed for kernel developers. They are kind of a weird lot, even for programmers. Among other things, they are used to working at the command line.
What does "git" mean? The wikipedia page gives some insignts
Torvalds quipped about the name git (which means unpleasant person in British English slang): "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'." The man page describes Git as "the stupid content tracker". The readme file of the source code elaborates further:
The name "git" was given by Linus Torvalds when he wrote the very first version. He described the tool as "the stupid content tracker" and the name as (depending on your way):
- random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
- stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
- "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
- "gddmn idiotic truckload of sh*t": when it breaks
Git in its simplest form is on a local machine. This is useful for some things, but many of the benefits come from putting code on a remote repository.
Most large software companies maintain their own git repositories. Setting up a command-line repository is relatively easy. Web based interfaces are also possible.
There are also public repositories. Here is a short list:
Github and bitbucket are the two best known of the public repositories. Both offer free public repositories. However, getting full use of either requires a paid account. However, both sites offer students and faculty free professional memberships with a restriction that the projects must be educationaql and not commercial. Bitbucket creates the repo automatically. Github makes you request it, but the process is easy.
Git seems to be better supported on JetBrains IDEs (Intellij, PhpStorm, and Android Studio). The JetBrains IDEs make it relatively easy to do commits and pushes from within the IDE itself.
Awais Khan (in CSC 445) found this link to activate your free GitHub .edu account: https://education.github.com/pack
Git softare is available for Linux, OS-X, and Linux. You can get it from repositories in Linux with apt for Debian-based systems and dnf or yum on RedHat flavors of Linux.
The git software may be downloaded from https://git-scm.com/ . There are also quite a few tutorials available.
Your local repository is in a directory called .git . On *nix systems (such as Mac and Linux) the leading period means the directory is hidden. On Windows systems the .git repository is visible.
The .git file normally is created in the root of a project. Normally each project has its own repository. For classes like CSC184 and 254 I suggest a folder be made for the course. Create the repository in the class folder instead of a different repo for each assignment. Your IDE may whine about this, but it goes along and does work well.
The main structure in the .git folder is a tree structure consisting of nodes. Each time you do a commit you create a node. Each node gets assigned a hexidecimal number from an SHA hash.
- commit -- A significan point in the code. You put in a message that explains what happens at that point or explain why that point in development is significant. Another relevant XKCD cartoon. Sometimes the only significant thing that happens is that you finished a work session. One thing that is important is that commits are about what just happened. Commit messages describe what you just did; they don't try to predict what you will do next.
- master -- This is the main branch of the repository. In the above cartoon the master is shown in blue. If you want to get the latest working version of your project, you will probably clone the master
- branch -- A branch is a special node. I is basically a node where the project "branches off." In the above XKCD the branch is in green. Changes made to that branch will not affect nodes that are part of master
- merge -- bringing a branch back into the master line. In the above XKCD cartoon you can see a branch that was merged. This was kind of a silly branch because there were no commits in master.
- push -- Move your commit (or last few commits) to the remote repo. Normally you will do a push right after a commit. But sometimes you will do commits to just mark significant point of the code
These steps are not really needed. But they are a good idea. Doing this once will set your name across all repositories. Substitute your name for Max Griffon.
git config --global user.name "Max Griffon"
git config --global user.email mgriffon99@missouriwestern.edu
git config config --list
Open a command prompt window. Use the "mkdir" command to make a directory, then use the "cd" command to change into the project directory. If the directory already exists, you can just go to that directory with the cd command.
In the root of the project directory, do the following command:
git init
That's it. In Windows do a "dir" command. On *nix systems, do the "ls -a" command. You should see the .git directory.
Next, you need to get the repository started. Make sure there is at least one file or folder in the directory. If there aren't any, you can make one called "about.md"
Now do the following commands:
git add .
git commit -m "First Commit"
The period after git add basically means "evertying you find in this directory or its subdirectories."
Adding a remote. I will use github in this example. It is for user mgriffon99 and for the csc254 course
git remote add origin https://github.com/mgriffon99/csc254.git
The term "origin" is very mystic to a lot of people. "Origin" is notthing but a name for the URL where the remote repository is located. Basically, typing "origin" in a command is like typing "https://github.com/mgriffon99/csc254.git". Which would you rather type? Origin is just a traditional name to use. If you look up git tutorials they will typically use origin. I suggest that you use it until you are comfortable with git. When the time comes you can actually have multiple remotes. For example, I currently am working on a project that has two remotes. "Origin" points to github, and "production" is what I use to actually deploy the project.
This is generally easy. In the menu click on VCS, then the Import option. The one I am showing is in PhpStorm and it might be slightly different in the other IDEs. Then create a git repository. There might be a picture that shows up around here if I figure out how to get an image into markdown.
You should be able to follow the prompts on the screen.
If you are in an IDE, just go to the VCS menu item and then make the appropriate choice.
If you are working at the command line, do the following
git add .
git commit -m "A relevant comment"
git push origin master
The above is the simplest case. It assumes you do not have any branches. As you get branches you can view various totorials and modify the push command to do also manage branches.
I may ask you to turn in a log of your git commits. You can get a bulky version with the following command:
git log
You can also get a neater version with the following command. I created a script called "gitlog" with the following command in it. If you are in windows you could make a gitlog.bat file to do the same thing.
git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short