Team coding
Borrowed from Elle K at the Linux Academy Blog


A wholly non-comprehensive guide to quick starting Git + GitHub.

Git Structure

Git is a CLI (Command Line Interface)-based local version control program used with the ubiquitous remote server warehouse GitHub. Note that Git can also be used standalone for local version control (not just with GitHub), but is most often used with GitHub for collaboration and cloud storage.

Setting up Git

Follow the instructions here to briefly configure your preferences.

A Note on Workflows

  1. Git doesn’t like empty directories. If you like to create your file trees in advance, put an empty text file in each so Git recognizes those directories when you add and commit them.
  2. No matter which way you look at it, you always have to create an empty remote repo on github before you can hook it up to your local project directory. In most tutorials they do the local stuff first, then switch to the remote repo creation, and then switch back to local to finish up - but I think that’s confusing. So we’re going to do the remote step first and then do all the local stuff after.

Before Anything Else

There are two commands that I use constantly in git. They are git status and git log --oneline. I use git status almost after every step to make sure the changes I made were what I wanted them to be. Use them often so you don’t get lost like I do.

Local Git Workflow

  1. Create a new repo on Github using the Github GUI. Don’t add any files to it yet!
  2. Create local directories and files
  3. Navigate to project directory in Terminal and then git init —- (to add git service to your project folder)
  4. ls -la to make sure your invisible .git file was created. If it was, then you now have git version control for all elements in your project folder.
  5. git add <filename> —- (adds changes to middling “stage” before “committing”), or more useful, git add -A to stage all.
  6. git commit -m “type descriptive message here” —- (commits save a version of changes with a message that can be referred back to later); also takes argument -a, like git commit -am “message”, to commit all staged changes.

Remote Git Workflow (Connecting Git + Github)

  1. In your terminal, navigate to the empty github repo we created in the first step. Copy the URL.
  2. git remote add <declare alias for remote repo, usually “origin”> <insert URL of remote github repo> —- (adds a remote repo). Type git remote to see which remotes are remembered.
  3. git push <declared alias for remote repo, usually “origin”> <insert branch, “master” for main branch>. If you don’t remember what branch you are in, type in git branch and it will show you.
  4. Refresh your github repo and it should reflect the new contents you pushed to it.


Now we’re all setup! If you are working alone, you can just repeat the local workflow for each new change (git add -A, git commit -am “message”) and then push it to your remote github repo (git push <alias, usually “origin”> <branch>) to save the commit “in the cloud” so to speak. However, if you are collaborating with other developers that are pushing and pulling from the same remote github repo, it’s a good idea to git pull before you start work each time and before you push anything. This updates your local repo with changes made by other people to the shared remote repo. More information on how to work with git remotes can be found here.


  • git pull = git fetch + git merge
  • git fetch = “Fetch branches and/or tags (collectively, “refs”) from one or more other repositories, along with the objects necessary to complete their histories. Remote-tracking branches are updated (see the description of below for ways to control this behavior).”
  • Use git pull to keep local repo up to date after remote repo connection has been established. Before continuing on project each session, always git pull first to get the most recent updates. General rule of thumb is to always pull before push. And always pull often!
  • git merge = “Incorporates changes from the named commits (since the time their histories diverged from the current branch) into the current branch. This command is used by git pull to incorporate changes from another repository and can be used by hand to merge changes from one branch into another”
  • References to “HEAD” basically mean the most recently checked out directory that Git is focused on.

Useful Commands

  • man <command> - manual
    • when in a man, navigate with f (forward), b (back), q (quit)
  • git status - gives you the status of added files, commits, etc. I use this after every other command to check things worked as expected.
  • git log - shows a full history of repo. Use git log -—oneline to show condensed one line version. Use —author argument to see by author. Use —since=YYYY-MM-DD to set parameters on history. —until=YYYY-MM-DD works the same as well.
  • git diff - shows difference between old version and new versions of files.
  • git branch - shows what branch you are on and what branches are available.
  • git branch <name new branch> - creates new branch with declared name
  • git checkout <name of branch> - checks out git version-controlled branches. Will also update HEAD to set the specified branch as the current branch.
  • git show HEAD - shows where the head is currently pointed.
  • git reset HEAD <name of staged file> - unstages added files. Use git status to see names of staged files.
  • git mv <first file> <new name of first file> - Git uses mv command to effectively change the name of a file.

One More Thing

Besides using Git for just your own projects, you can use Github to get involved with the open source community. Since all repos you can see on Github are public (there’s a private option, but you have to be a contributor to see them), you can “fork” them and make edits to the code. If you think your code fixes or improves upon the original, you can submit a “PR”, or pull request, to the author and they will decide whether to include it in the project or not.

  • fork a project - “A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project. Most commonly, forks are used to either propose changes to someone else’s project or to use someone else’s project as a starting point for your own idea.”

Happy Gitting!