Git Basics

Early on you will using git to get code (pull) from a remote repository (on github), writing your own code, tracking it with git, and moving (push) the code from your computer (local version) to github.

When using git locally (on your computer), you have been running the commands in Terminal (Command line).

A git command has a minimum of 1 argument.

Git commands are always executed by first typing git

The first argument is the command (or verb), like

• git init (initialize a new git repository)
• git push (send the code to a remote location)

The second(+) argument gives the first argument context (when needed)

• git add . (add all files in this directory)
• git pull origin master (get all files from the url that has an alias of origin, from the branch master)

Lastly, flags can be added

• git remote -v (git show remote(s) and be verbose(give more detail))

Here is a table of our commonly used git commands that we've used in this course so far:

git	Argument	Flag(s)/Additional arguments	Description
git	init		Initializes a new repository
git	add	. or filename	Takes untracked files and adds them to the staging area so that they can be committed
git	commit	-m 'some message'	Takes a snapshot of files in the staging area/ saves this version of them as a commit
git	remote	-v	Shows the remote repositories associated with the local repository. Most repositories have an alias for their urls like origin or upstream
git	pull	upstream master	Gets files from a url with an alias of upstream from its branch master
git	push	origin dev	Sends files to a url with an alias of origin to its branch dev
git	log	--oneline	Shows a log of commits of a repo (--oneline shows a truncated message)q to exit
git	status		Shows the state of files in a repo (untracked, modified, staged)

Git quick reference guide with a more complete list of git commands

Note: fork is not on this list because fork is not a git command; it is github-specific for copying a repository on github to a new location on github.

Git VCS - Branches and Merging

Git is a VCS (Version Control System). There are a few popular ones, but git ends up being a top choice because of its branching and merging feature.

If we think back to our past projects, when we wanted to implement some major changes to our code and failed our popular options were to

• ⌘Z throughout our files and hope for the best
• Comment out a ton of code and hope to restore the functionality of our code to a previous version
• Seriously contemplate coding out our project from scratch again
• Curl up into a ball and hope the code would revert via magic

Git's about page has 4 great reasons why it works so well for individuals and large teams.

• Frictionless Context Switching - Switch between branches, whenever! No worries!
• Role-Based Codelines - Have many versions of your code - Production, Development, Day-to-Day etc.
• Feature Based Workflow - Create a new branch for each feature
• Disposable Experimentation - if a branch doesn't work out, you can just walk away or toss it. It has no impact on the working code

Git Flow

You may be thinking 'this sounds too good to be true!' It's not! But there is a catch! Git requires changing the way we are used to working on projects. Which means it takes some time and practice to learn to use git.

Check out this visual guide on Understanding GitHub Flow