#A beginners guide to Git (and GitHub).
This guide is meant to be simple, and skips over a lot of things. Its meant to be a getting started guide and not an fully fledged manual. Keep this in mind and read around it.
I assume you have Git installed correctly. Get it here..
##Getting started
To initialize a git repo, open up your Terminal, cd into the correct folder and type:
git init
Now it is time to do your first commit. To do this you need to add files to be "staged". This means adding them. To see which files have been changed, type:
git status
To add all this files to the commit (your commit won't work without this), type:
git add --all :/
Now if you type git status again, you will notice all the files have been
staged. If you are happy with the state of things and want to make a commit,
type:
git commit -m 'your message goes here'
This will commit the changes, with the commit message you type in. Copy this
process for all future commits. add then commit.
##Pushing to GitHub
Ok so now you are ready to push to GitHub. First of all, you need to set up a remote. A remote is where your repo is stored on the server you are pushing to, in this case GitHub.
Make sure you are still in your projects directory, and type:
git remote add origin http://github.com/example/repo.git
Now you are ready to push. Type:
git push -u origin master
You will then be asked for your username/password.
##Cloning someone else's repo
Say I want to clone my friends repo to work on on my machine. I can type this:
git clone http://github.com/friendsuname/ourrepo.git
This will make a folder in the current directory called ourrepo, which
will contain the files from the repo.
##Branching
To create a new branch stemming from you current one, type:
git checkout -b new_branch_name
This will create a new branch and switch you to it. To switch back, type:
git checkout previous_branch
###Git won't let you checkout a branch?
Git will not let you checkout another branch until you current branch is clean.
If you current branch is not clean, type git stash, then do the checkout,
then type git stash apply. Your changes that weren't applied now will be on
the branch you just checked out.
###When should I make branches?
Its entirely up to you, but this is what I do.
I always have a develop branch. master never has unstable or breaking code
in it, and develop doesn't get merged into master until all tests are green.
I start up a new branch from develop whenever I am working on a new feature,
such as a new class or something similar. I only ever branch directly off master
when I need to hotfix the live build.
In short, master is always stable, develop is for new stuff. When all tests
are passing on develop you can then merge it into master.
##Merging
If I want to merge a the current branch with another, I can do this:
git merge another_branch
Or I can specify the target like this:
git merge another_branch target_branch
##Merge conflicts
If you try and merge two branches that have changed the same file/s differently
you will get a merge conflict. Don't panic, all isn't lost. To see the unmerged
files, type git status. Git will outline where the problems are in the
relevant files. Check out the link below to learn how to resolve them!
Git docs (Basic Merge Conflicts)
##Working with others.
###Fork and Pull model
The best way to work with others on GitHub is by using the fork-and-pull model. This is how it works.
I want to work with Josh on something. I go to his repo on GitHub and click on
the Fork button. This creates a copy of the repo on my GitHub account. I then
clone my fork of the repo, and work on that as normal, pushing to my fork as
I go.
When I want to merge my code into Josh's repo, I go to my fork on GitHub, and
click on Compare and Review (its green), and then compare against the master branch. I
can then open a pull request from this screen, adding some comments about
what I have done.
Anyone else who looks at the PR will see what I have changed and why. They
can also comment and suggest changes before the PR is merged into the master branch, and
any changes I push to my fork will show up if I add them before the PR is
merged. If anyone wants to test my changes, they can add my fork as a remote
to there own local repo, and checkout the branch, and even work on it and send
me PR's for my fork.
This is a great way to discuss changes before they go into the live build, so get everyone involved in the conversation. GitHub will show you line by line changes on every modified file in the commit, and you can comment on files line by line. Use these features!
When Josh is happy with the changes I have made, he can click Merge this PR and merge the code with the master branch of the main repo. Thats it.
###Getting upstream changes
When you have forked and cloned the repo your team is using, you will need to
set up a remote so you can get the upstream changes that are added to it as
and when it is changed. I do this at least once a day, so I am always working
with an up to date code base. Its unlikely upstream/master will change this
much, but it might if you are close to a deadline.
Set this up by adding a remote upstream and then running fetch to get the upstream
changes:
git remote add upstream http://github.com/friendsuname/ourrepo.git
git fetch upstream
Now if you look at all the branches you have using git branch -a, you will
see a branch called upstream/master. You can checkout this branch and if you
like before merging it. Then merge it into your master branch by doing:
git checkout master
git merge upstream/master
###Rebasing
Ok so you have done the steps above to add the upstreamremote and you have
merged the upstream/master branch into your master branch. Now you need to
get this code merged with your develop branch (if you are using the same
branching strategy I described above).
The safest way to do this is:
git checkout develop
git rebase master
This will rewind your develop branch to its most recent common commit with
master, and then apply the changes on top of it. This is the best way to do
this, as it preserves all the commits correctly, and you don't have any nasty
looking merge commits. If you get merge conflicts, resolve as usual.
##There is something I am stuck with r.e. the 'Fork and Pull' model.
Checkout out this great article on GitHub for an explanation of the process, and how to merge in upstream changes, with screen shots! Also a link on how to Pull Request!
##Everything has gone wrong and I want to go back to X commit. Help?
If you want to revert to a specific commit, type:
git reset --hard commit_id_here
To be clear, this is not the commit message you added, but the commit stamp. If you want to remove all your changes since the last commit, type:
git reset --hard HEAD
Which will reset you to the commit HEAD, which always references the most
recent commit. If you want to go back further and use HEAD as a reference, type:
git reset --hard HEAD~n
Where n is how many commits you want to revert.
###Questions?
If you have anymore questions, don't hesitate to tweet @benjaminparnell or email me on me@benparnell.com.
Also check out the Git guide if you want to look up something.
It might seem like an uphill battle now, but you have no idea how useful this is.