Lot of people have asked this question so many times, on how to handle continuous integration and deployment with a team which is distributed across the globe.And also how to use Software Configuration Management along with this process.
I will try my best to answer these questions in this blog post. I am also working on a course on Git version control system which will be ready in a week or so. if you are interested to get early bird discount,Please register at the end of this page.

Prerequisites:

Git :
You will need a Git repository to place your code and other project files.Git is a very powerful version control system. And it has every feature you will need for version control. And its one of the popular choice of developers across the globe.
Development Sandboxes:
You will also need a development sandbox to do the testing of the new code changes and new features. You probably will need a full sandbox which has all the data from production org. If its not possible to get a full sandbox, it will be helpful if you can at least contain a sampling of production like data.
Every developer also have their own developer sandbox. But i will recommend to have some test data in the developer sandbox.
How we will pull updates from the sandbox??
You have so many powerful tools like Solenopsis, Mavensmate, Force.com IDE, or an Ant tool to pull updates from the sandbox.Every developer can have its own choice of which tool he wants to use, but it’s important to note that you will need a tool with which you can do a destructive change push that overwrites objects as well as code. And another point to make sure is that the data that comes back also needs to be consistent.
Automated Build Process:
This is not a prerequisite but I highly recommend to have an automated build process.With automated build process you will be ensured that your development environment is fully updated and you won’t have to spend time to do it manually.You can also schedule jobs to run test cases. There are tools like Jenkins that will help you to automate your build process. With Jenkins, you can push your code from development instances to all the way to release to production.

Step by step process to develop a feature:

I will be using Solenopsis commands to explain you this lifecycle.

step 1: Push to sandbox

Before you start to develop new features it’s important to have a clean slate. You can pull the latest code from git and then push these changes to your development sandbox.
commands:
git pull
solenopsis destructive-push

Step 2: Crate a new branch for this feature

If you are not sure about this feature development, it’s important not to effect the stable release, I will recommend to create a new branch for this new feature and once you are satisfied with the feature and you have tested it, you can merge these changes to main branch or the master.
command:
git checkout -b mydevelopmentbranch

Step 3: Configuration

Configuration can be done any point of time in development. But I will recommend to do this first because that way you will have a cleaner repo listing.
solenopsis pull-full-to-master
git add objects/MyObject__c.object
git add objectTranslations/MyObject__c-en_US.objectTranslation
git checkout .
git commit -a -m “My configuration changes”

Step 4: Finish up your code changes

This is the place where you will spend most of your time. It’s the developing of this new feature. Once you have finished up your changes and also all your test cases are written then we will commit these changes to git.
if let’s say you have to develop multiple features you can commit the changes after every feature is finished, that way you can always revert back to previous commit, if you are not satisfied that will save  lot of time in redoing your work.
git add classes/MyNewClass.cls
git commit -a -m “My coding work”
Git commit happens in a two-way process. First is to add and then commit your changes.

Step 5 :Rebase

Rebase is one of the trickiest part in this whole process. When you are working with a team of developers, there will be cases depending on the length of the feature, they might have finished their changes and committed to git before you have committed your changes. Now this might result in conflicts while merging. So before you commit your changes, you need to rebase with master.
Rebase will take all the commits you have done during the feature development and re-play them over top of the code that exists in git.Chances are that rebase will be  successful but sometimes you might come across merge-conflicts.At the time of merge-conflict you need to manually sit down and resolve these conflicts which can be very painful. So the best way to handle
merge-conflict is to prevent them.

How we can prevent merge-conflict:

• Try to keep yourself updated with what code changes or files other team members will be touching and try to stay away from the code they are touching.
• Always add new methods to the bottom of the file. This might result into merge-conflicts but these are easy to resolve.
•  Also try to get a big picture of what your code is doing and how it will effect other areas. If you don’t get this part right then it will make the merge process very complicated.

git checkout master
git pull
git checkout mydevelopmentbranch
git rebase master
After following these preventive measures, if you still come across merge conflict, below are the steps to resolve them.
Step 1: When you have a merge conflict, it will always mention the file names, open the file in the editor and look for this “>>>” combination string.This is place where the conflict occur, sometimes removing these markers and adding the code changes will resolve conflict.
Step 2: Rebase early and rebase often
Always keep this point in mind “Rebase early and rebase often “. Its always wise to rebase everytime someone commits there changes to master. Rebase early and frequently will make your life easier.

Step 6: Push the rebase

this step is only required when you have changes to the master while you were working on your development branch. If there were no commit to the master you can skip this step. Otherwise go ahead and do a full push to your sandbox and re-run your test cases. Make sure you didn’t break someone’s else test cases and they didn’t break yours.

Step 7: Commit to master

After you are done with your changes, your feature is fully -developed and tested, you have also done rebase,now its the time to commit your changes to master . Let’s merge first
git checkout master
git merge –squash mydevelopmentbranch
git commit -m “UID – The awesome new feature”
git push

Step 8: Cleanup

Once you are done with the commit. Now you will have reduntant code. Because your local branch and master have same code. so its time to do cleanup. No point of keeping your local branch.If you have more work to do,then you must re-branch off of master and start the process all over again.
git branch -D mydevelopmentbranch

Step 9: Automated push:

I assume you have a automated system set up which is monitoring your git repository, and when they see there is anew commit and do the push.
Its always better to have an automated system to run your test cases. Its better to schedule your testcases to run twice a day and notify you of any errors that occur.