Git Tutorial - GameDevStudioUCSD/DrEric GitHub Wiki

#Git and GitHub (Under Construction)

Introduction:

Git is version control system widely used in both industry and academia that supports both individual and collaborative projects. GitHub provides a graphical user interface for git and free public online repositories to store projects. As a version control system, Git keeps track of changes made to a project in increments, backups up a developer's progress, and allows developers to rollback to an earlier state in the project if desired. The CSE department at UCSD teaches students the basics of using git; However, this document serves to teach students who haven't taken CSE 15L and to highlight some collaborative features of git that GDS holds near and dear because they make our lives easier.

##Basics: The following commands are the most frequently used throughout the git workflow:

 git clone
 git add
 git commit
 git status
 git push
 git pull 
 git rm
 git checkout

git clone

This is the first command you will use in git in order to get access to the repository. In each repo there is an https clone link that you just copy and past following the command in order to get your own local copy of the files. For example:

 git clone https://github.com/GameDevStudioUCSD/DrEric.git

git add

Now, let's say you made some changes to your local files or want git to notice some new files in the repo. Git add is the command that does so. Git keeps watch over your files but must be told to do so: this means you have to use this command to let git know your file exists or to make any changes. Once a file has been added, it is now tracked by git and if you have made changes and used git add, it is staged for commit. For example, if you made a new file coolgame.c and want the git to notice it:

 git add coolgame.c

git commit

Once your changes have been added, you must commit to those changes. This command "saves" your changes in git. Only your added files can be committed. You can (and should) specify a message about your change with the -m decorator. This looks like:

 git commit -m "I'm a short message telling other developers what this change did!"

Note: Committing only saves your files locally. There is another step to save your changes online

git status

If you lose track of what files need to be added, are added, or otherwise, this command reports a wealth of information about the current status of your repository. It tells you which files are not being tracked by git (which need to be added), which files that you have modified (to be added as well), which files are staged to commit (have been added and need to be committed), and other useful things. This will be the command you make the most use of throughout your git career. All you need to do is:

 git status

git push

Once you have committed files, you must move those changes to the repository online. After you push your changes, then any developer with access to the repository you're working on can pull your changes. This command only needs:

 git push

git pull

Since you're working with many other collaborators, you won't be the only one making changes to the main, online repo. This command will update your current repository with all the changes that have been pushed by other collaborators. It's generally a good practice to pull often to keep your project up-to-date and to avoid merge conflicts when your changes contradict others' changes! Like the last few commands, this simply needs:

git pull

git rm

If you want to remove something from the repo, use git rm so the git stops watching it too. For example, to remove some file foo.c:

git rm foo.c

git checkout

This command does a couple of handy things. For one, it acts as a type of undoing fail-safe if you find out you don't like some of your changes. Say you run git status and see you've modified some file foo that you'd prefer not to keep. Running the following command will return foo to its values from the last commit:

 git checkout foo

Checkout also lets us switch to other branches. You can think of a branch as another work-space where your actions won't break the primary build. Checking out branches looks the same as checking out an old file version. Say you have a branch bar. Running the following command will switch your current branch to bar:

 git checkout bar
⚠️ **GitHub.com Fallback** ⚠️