Version Control: Git

Introduction

Git is a relatively young but powerful open source version control system compare to CVS, SVN and others.  It is famous in Linux communities.  The Linux kernel source code is using git as version control now.  More Git tools is available for Window users now.

Git doesn’t has a centralized version control server/repository like CVS or SVN.  Instead, the repository exist in each developer’s machine.  Once you have git system installed, you may start your project to enjoy git version control locally or offline.  You may carry all version control operations like commit, revert, branching, tagging and etc. in your standalone PC.  All your git work is stored in a hidden folder .git of your project.

You may however, share your repository with collaborators in your team by cloning your git repository.  To share work in team, you may push and pull with each other’s git repository.  You may also select a git repository in the team as a origin repository for everyone.  So you have a centralized control of your version control commits.  You may customize the collaboration workflow that is comfortable for your teams.  Git will suit your needs in various dimension.

Basic Git operation

init

Initialize a git repository, whether it is bare or working repository

clone

Clone repository to share repository in team work. The source repository will automatically become origin of clone repository.  You may clone local or remote repository of various source like ssh, git protocol, http or local.

add

Add changes to staging area and waiting for commit in later stage

commit

Commit all changes added to staging area

push

Push all committed snapshot to another git repository

pull

Pull all update committed snapshot from other git repository

Git Branches

Unlike other version control system, branching in Git is common and cheap operation in day to day development works.  Git doesn’t encourage developers to work with master branch directly.  Instead, all development work should work in new branch.  And merge to master once complete.

Git Best Practices

Two things you should never do in git:

• NEVER force a push
  If you find yourself in a situation where your changes can't be pushed upstream, something is wrong. Contact another developer for help tracking down the problem.
• NEVER rebase a branch that you pushed, or that you pulled from another person
  Rebasing published branches can lead to duplicate commits in the shared repository.

In general, the preferred workflow is:

• create a branch from master, check it out, do your work
• test and commit your changes
• optionally push your branch up to the remote repository (origin) OR
• optionally rebase your branch to master (if your changes are unpublished)
• checkout master, make sure it's up-to-date with upstream changes
• merge your branch into master
• test again (and again)
• push your local copy of master up to the remote repository master (origin/master)
• delete your branch (and remotely, too, if you published it)