Getting Started with Git and GitHub
About Git: is a distributed revision control system with an emphasis on speed. Every Git working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server.
About Github: is a web-based hosting service for projects that use the Git revision control system. The site provides social networking functionality such as feeds, followers and the network graph to display how developers work on their versions of a repository.
Getting Started with Version Control (VC):
VC is the process of recording the history of changes to files as they are modified. Users can go back in time and get old versions and identify where changes were introduced.
protect against changes—accidental or otherwise—and be able to access a known good version of a file
track down problems and make fixes to previous versions of files
allow more than one person to modify project files simultaneously (programmers refer to this as parallel development)
retrieve an older set of files (if requested by a customer or manager, for example)
Git represents the current state of VC, in that: it is distributed. A distributed VC tool gives each user a complete history of all changes to the files on which they work. So no matter where you are you can access previous versions of files and changes can be merged together for release or further work.
Git is different from VC tools because it is distributed. Other VC tools are centralized and provide only a single place, the repository, into which users store their changes on a regular basis. In this model users work without a personal copy of the change history; they only have the set of the files they’re currently working with.
Repo: Git maintains a database of all previous file versions in a repository usually located in a directory called .git. this includes contents of the files, directory versions and additional housekeeping information about current work, other remote repositories we’re sharing with, current settings, and so on. In Git we have a separate repo for each of our projects.
In UNIX-style systems (like Mac OS X and Linux) names that begin with a . are hidden by default so the repo is usually invisible during normal work (except on Windows).
Committing changes: Each project will have a set of files that we’re working on and editing. As we complete changes to our working files we add the changes to the repo; this is called committing changes. We’re not fully committed to our changes as we can always retrieve old versions and make changes to the changes. We can also access a summary of our work against previous versions to see what we’ve done so far.
Working copy: The set of files we’re currently working on. We can easily change the working copy to a different version whenever we want.
Before going further let’s install Git and set up a small test repo to work with.
Linux: simple matter of using your package manager to install git (and possibly Git GUI if it is a separate package).
Mac OS X either use the Git OSX Installer or you can use Mac Ports.
Windows: users who use Cygwin can use the Git from Cygwin; Otherwise Windows users should use the the native Windows Git package: msysgit
I installed Git and Github on Ubuntu: http://help.github.com/linux-git-installation/
The quickest way to get started is to use the Git GUI client. Type the command git gui at the command prompt.
Select Create New Repository.
Enter the name of a new directory.
Git will create the directory and initialize an empty repo.
To create a project directory, the command prompt is:
You should then see a message like the following:
Initialized empty Git repository in /path/to/your/directory/.git/
If you look in the project directory you should see a directory named .git (on Mac OS X or Linux you will need to use the command ls -A to show the hidden .git directory) In your newly created project directory make some new text files using your favorite editor. You now have some changes that are not under version control, in Git these are called unstaged.
You can retrieve the same information from the command line with the command git status.
Git is a little different to most VC tools. Adding changes to a repo is a two stage process. All changes are staged in the index, before they’re committed into the repo.
The index allows us to add, remove and modify changes on the way to building a commit. useful for:
Our working copy may contain more that one set of changes and the index allows us to cherry pick which ones will be part of the next commit.
You can incrementally make changes (using your own workflow) before making a commit.
You’re able to stage and unstage changes in more complex work flows
git add command is used to add the content to the index.
git rm command is used to remove files
git mv moves or renames files.
Before using Git we need to tell Git who we are; our name and email address. From the Git GUI interface select Edit > Options and fill in the top two fields under Global. Leave all the other values as they are.
OR from the command line:
$ git config --global user.name "John Doe"
$ git config --global user.email "[email protected]"
Now we can add our changes to the index and commit them to the repository. First select both files on the Unstaged Changes pane.
Then select Commit > Stage To Commit (ctrl+T). The display then shows that we have no changes waiting to be staged, but we do have changes to be committed.
If it’s unnecessary to specify which files to add:
Now that our files are staged, we can commit our first changes to the repo. Each time we make a commit, Git expects an informational message that’s added as part of the commit; if fail to provide a message no commit will be made. Generally we add a single line description and then a more detailed message. Click theCommit button and the changes are committed to the repo.
$ git commit -m "A message about your changes"
The latest version in the repo—called HEAD—is the same as the contents of the working files. Running the command git status should show the message:
$ git status
# On branch master
nothing to commit (working directory clean)
We can always refer to the contents of the last commit as HEAD and the contents of the commit prior to that as HEAD^1 (and HEAD^2 for the commit prior to that, and so on). However that quickly becomes error prone and hard to use, so Git gives each commit a special id which is an apparently random string of 40 characters called the sha1 hash. It looks a like this: a90973cbe16d5a0cf4fcd5cca659f4a4587d7cb5.
Every commit across the world has a unique sha1 hash and when you come to share your history with other Git users (for instance, other members of the web team) it’s a unique way to refer to your work and its history. If two users have the same sha1 in their repo then they are referring to the same piece of work. In practice, humans can usually just refer to the last few unique digits in the sha1 to uniquely identify a commit.
As a user you’ll generally only see a sha1 hash used to represent a commit; however, “under the covers” the hash is used to identify files and directories (which form trees in Git terminology), and other objects. This has an interesting, and highly desirable, effect. When you rename a file (or move it in the directory tree) its sha1 hash remains unchanged, but the tree that refers to the file and its name changes. This means that Git can track changes and moves far more easily than tools such as Subversion.
Pretend you’ve done some work and make a change to one of the files. Git GUI will show you the changes.
To view the history of commits to a project:
Git also has a second GUI application called gitk that displays the history of commits in a graphical format. In Git GUI select Repository > Visualize All Branch History.
Notes from: http://help.github.com/ and http://articles.sitepoint.com/article/version-control-git