Fear change? Files got you down? Meet Git, the Cesar Millan of version control. Git is hard so you don't have to be.

how-to-git.md

Git: The File Whisperer

Dominate unruly files with the Git technique

You have a folder with some files in. Right now you have no way of finding out what those files contained yesterday, or which of them is the latest version of that doc you've been emailing back and forth with those other change makers. If you are really, really disciplined, there is a tiny chance that you won't lose something important, at some point. But no matter what delusions you may have picked up, you are, like the rest of us, fallible, so chances are you already did.

Lets discipline these unruly files with the wonder of version control. Bring out the git.

The first step is to run git on your local project directory, turning it into a local git repository.

Install git and configure your author details

git config --global user.name "Your name here"
git config --global user.email "you@here.com"

Add git power to your project

cd my-awesome-project 
git init

COMMIT ALL THE THINGS.

git status
git add [the files I want to commit, or -A for everything]
git commit -m "[Pithy description of the changes made]"

...rinse and repeat the add and commit steps as you make changes. It's all local, it's all versioned.

At some point you are going to want to share some files with others. That's where github.com can help. You can create a shared repository on github, and push a clone of your existing local repository (with a full copy of the history) to it by:

git remote add origin [git hub repository url]
git push -u origin master

and you keep the remote github version up to date by further pushes after you commit to your local repo:

git push

The key point is, you commit to your local repository, so commiting code is not the same as sharing it. You commit as much as you like, and when you're ready, you can push your changes to the remote github repo to share them. I tend to push after every commit.

When some one else has committed and pushed a change to the shared repo, you can get those changes by pulling:

git pull

You may find that the pesky others have changed files that you have also changed. Pulling those changes will leave you with a merge conflict. You have to manually pick through the files that both you and the other have changed, and figure out how to re-write the file to take account of both sets of changes. This is a hard problem, as you need to understand both why you made your changes, why they made their changes and figure out the union of the 2 things.

It's wise to avoid merge issues as much as possible.

• Commit and push small changes, often. Remember to pull before you push.
• If you're working on a small project, with a team of people you can easily talk to, discuss what you are working on, every day.
• Only commit and push changes to files that you definitely need to change.
• If git status shows you that a file is changed and you didn't mean to change it, go take a look and revert it if you didn't mean for it to have changed.
• Focus your commits on 1 issue at a time. Don't fix a bug and also re-format the entire file in the the same commit, otherwise it's hard for those merging you change to see the wood of bug fixes from the the forest of re-formatting changes, and they may miss it all-together.

This is the Git way.

Dominate your files lest ye be dominated.