An introduction without commands
This introduction is meant to give you a basic understanding of what git is. It also teaches some of the lingo of git.
Git is a version control system, which can be used to create snapshots of your software project. A snapshot is called a commit. With git you can look back in history at your project by browsing through the commits and possibly revert a faulty change.
A commit should not be considered a full copy of the project, but a collection of differences between this version and the previous one.
The project including all files created and used by git, is called a repository.
Let's say you have a working version of your project. Let's call it version 1.0. Now you start working on adding a new feature. While under development, parts of the application won't work correctly. When a critical bug arises in v1.0, you can't fix it in your current development version and wait until it can be released. You have to keep a copy of v1.0 around to fix that bug immediately.
Instead of creating physical copies of the project, git allows you to create a virtual copy called a branch. You switch from one branch to another by doing a checkout.
Besides branches you can also take a copy, which is frozen in time. This is called a tag. Tags are usually released versions of your application. Let's say I've released version 1.0.0. Now a bug arises which is solved and released. This released version is tagged with 'v1.0.1'. So you see, the code of tag 'v1.0.0' will never change.
It's common to have a master branch, which is a development branch with only working (and tested) code, plus branches for each feature which are currently under development.
Now you have multiple copies of your project. At some point you need to combine work done in one branch with work done in another. There are 2 ways of doing this.
Let's assume that a feature is completed and I want to add it to the master branch. You can apply all the changes made in the feature branch to the master branch. This is called a merge.
In another example the feature isn't done yet, but you want to update the feature branch with the bug fixes done on the master branch. Instead of doing a merge, you can start with a clean copy of and apply each commit of the feature branch to the new copy. This is called a rebase.
Note that when to use merge or rebase is under heavy debate.
In some cases you might have edited the same file in both branches. On a merge or rebase, git will try to merge the changes automatically. If you've edited the same line of code, the automatic merge can't be done and git with notify you that there is a conflict. You need to resolve the conflict manually to continue.
Hosted copies are called remote repositories. A rremote repository has all the features that you have locally, including branches and tags.
Even though be project probably originated on your computer, the central remote repository is commonly called origin.
The origin repository serves as the central spot when working with other developers on the same project.
Commits aren't automatically send to remote repositories. You need to manually push your changes. You and other developers can all push to origin.
You usually push to the same branch on a remote server. So you'll push the commits made in your master branch to the master branch of origin.
Commits made by other developers don't just appear in your repository, even if they pushed is to origin. You'll need to fetch changes from remote repositories.
Fetching will create read-only branches on your local system. The local copy of the master branch of origin is named 'origin\master' on your system. It should not be confused with your 'master' branch.
After doing a fetch, you can merge or rebase your copy of the remote branch with any of your branches.
A pull is simply a fetch, followed by a merge.
When you become involved with an existing project, there will already be a origin repository. You need to download a copy to your system. This is achieved by making a clone.
For (open-source) projects on GitHub (or BitBucket), you have read privileges, but can't write to the repository. That means that you can't push any changes to origin.
To overcome this, you can create a new origin, by having GitHub clone the repository creating a new origin especially for you. Your origin copy is called a fork.
After forking you should clone your own origin, not the original one. If you've already cloned the original project, don't worry you are able to change the address of origin at any time.
If you have a forked a repository, you might want to feed back your changes to the original project. To do this, you send a pull request to the developer of the original project. He/she will review your changes and can choose whether or not to merge them.
A pull request is always done at GitHub or BitBucket, never on your local machine.
When you create a pull request, you're selecting a branch on both your fork and the original project. Do note that when you push changes to that branch they end up in the pull request, event after the pull request has been send. Therefor is recommended to always create a new branch for a pull request named something like 'patch-fixedxyz'.
Git is originally a command line tool. In most tutorials you'll find command like
git pull origin master. Using it is recommended if you're really comfortable with the shell.
There are several GUI application to work with git. I recommend using SourceTree. A free client for Windows and Mac. Using it can be a bit challenging at first, but hang in there. It gives you a great overview of the repository and supports most features of git.