Git and GitHub

Tips and hints for working with Git. Lots of links too.

What is git? What is GitHub?

Git is a version control system that keeps track of changes to files, so that you can have a history of all the changes made to a file and you can revert to a specific version later on.
GitHub is a web application that provides hosted version control services using Git. You can sign up and create public repositories for free, but you should pay to create private repositories. There are other similiar services among which are GitLab, BitBucket and Gitent.

project directory: the directory that contains all the files of your project. It often contains other subdirectories. Different languages have different conventions for how to structure a project. Very often the toplevel contains a Readme file.
project root directory: the topmost directory of your project directory.
repository or repo: when a project directory is “packaged” up for Git
commit: one snapshot in time of the state of all the files in your project directory. Each commit is derived from an older one, it’s parent. Still you can safely act as if the commit contains every single file in your project directory
(git) server: a server (separate from your own computer) that contains a snapshot of your repo
GitHub: the most well known, publicly accessible git server

Safely keep copies of all your source code and related files
Efficiently store the source code over time, maintaining all the old copies too
Allow multiple teams or people to safely collaborate in a distributed environment
When necessary allow the developer to recover an older version of a file for some reason (bug, typo, accidental deletion etc.)
Create parallel branches of work to allow divergent changes to be created without interference.
Different versions for development and deployment; the deployment version should be a stable one

Commands done only from your top level “source code directory”
- git clone (create a new directory from a repo on GitHub)
Commands done from inside an individual repos local directory
- git add –all (add all changed files to staging)
- git commit -m “message” (create a “commit” with all staged files)
- git push (push all local commits up to GitHub)
- git pull (pull any changes made from GitHub to look at it locally)
- git status (see where things stand)

Important Don't do a git clone from 'inside' a local repo directory!

There are tons of online resources available for learning git. Below is a list of some that you may find useful:

What are the main benefits of using GIT when developing a project by yourself?
What are the main benefits of using GIT when developing a project with a team of coders?
What are the reasons to create a branch?
When several team members commit different changes on their local repositories, how do the reconcile their different changes in the main GitHub repository?
What are the advantages to having a staging area?
After discussing these “big picture” ideas, we’ll look at the internals to see what Git is actually doing when you branch, commit, etc.

create a local repository (git init)
create a GitHub repository and push your local repo to GitHub
clone a GitHub repository
create a temporary branch, make some edits, do some tests, merge it into your main branch, merge it into the team main branch
interrupt the work flow above to fix a critical bug by stashing your current work, checking out the main branch, creating a temp branch with the fix, merging it into main, switching back to your branch and applying your stashed work to get you back to where you were
pulling down someone else’s committed changes and resolving the inevitable conflicts that have arisen (by deleting theirs and using yours!) then pushing
making a temporary extension, and rebasing several times as other people are committing their changes to the main branch on the shared server
viewing your current status
checking out another branch
tagging the current version (e.g. v1.0 or v1.3 or v1.3.7)
cloning a tagged version