Basic git usage

Basic git usage

The most common git commands you'll likely use when contributing code to a repo.
Assumes you have already installed git and setup GitHub command line access.

Basic Terminology:

• track - To keep information about changes
• repo - short for repository; Any folder sub-tree that has been setup to be tracked by git.
• clone - an exact copy of a repository located somewhere else.
• local - located on your own computer.
• remote - located on some other computer. (The copy of your repository that resides on GitHub, for example)
• branch - the point where code changes (or commits) separate into 2 distinct paths, including all subsequent changes (or commits) added to the new path. This allows, for example, a release branch to remain stable, even while development and change not ready for release continues on other branches. It allows you to easily try changes you may or may not want to keep without modifying (then possibly having to later un-modify) the originating code branch. It allows multiple users to work independently on the same body of code without tripping over each other's changes and newly-introduced bugs.
• working directory - the path on your computer where you are currently editing files
• stage - to assemble a product in a preparatory area prior to deploying the finished product to its destination
• staging area - a preparatory location where a product is assembled prior to deployment as a finished product (in this case, a place where you prepare changes you intend to make to your repository)
• commit - (verb) to cause an action to occur, or to transfer something to a new location (in this case, to send or effect your code changes on your local repository) Also frequently used as a (noun) in this context to indicate an instance of a staged set of code changes effected on the repository.

Clone a repo

mkdir -p ~/projects
cd projects
git clone git@github.com:jlast35/hello.git
cd hello

Check the status of your local repo

git status

# If the folder you are in is not a git repository, 
# the command will warn you about this.
# Otherwise, it will give you a summary of the repository state

Check available branches and which branch you are currently working on

git branch

Checkout code from a different branch

git checkout <branch_name>

Update your local repo with changes others made to the remote repo.

git pull

Stage files to be committed

git add <path_to_file>
# or
git add -A
# to add all changed and unstaged files

Commit a staged set of code changes

git commit

# A text editor will open
# If you close the text editor without making or saving any changes, the commit will be aborted
# Otherwise, the first line should be a brief summary message of what the commit does, followed by a blank line,
# then subsequent lines (if any) should contain a more detailed description of specific changes made by the commit.
# Best practice is to use the imperative mood when describing changes 
# (as though issuing a command or instruction for git to change something in the code)
# This way, changes read as a high-level list of instructions on how to recreate the code state 
# and it also makes more sense when you are trying to debug what code change actions caused what results.

Check the commit history log

git log

# Note: Changes pushed by others to the remote repository will not appear here 
# until you have pulled those changes to your local repository.

Push your code changes (commits) to the remote repository.

git push