I am planning to implement continuous integration using Git,Jenkins and Github in salesforce.My query is regarding the repository structure.We have 3 salesforce environments Production,QA and Integration sandboxes.is it advisable to have 3 different repositories for the 3 environments or one repository and multiple branches.My concern with second approach is if we maintain a single repository the individual developer would get access to complete production codebase and he would be able to commit the changes to master branch.Please let me know which approach is the best one to go.In case first approach is advisable then can we merge two different repositories in github?
Your question does not have an easy answer, and it looks like there are lots of tradeoffs.
In our company we have CI with salesforce. Every time a developer checks in, our CI server runs an ant script, using the Force.com migration tool, and runs all the unit tests in a test environment.
We use a single trunk and no branches. We have different revisions of the same trunk deployed to different environments (dev, staging, etc.).
We thought using one branch per environment, ideally automatically deploying to that environment once we check into the right branch. we didn't see that many advantages on this approach and for the time being we haven't implemented it.
If you use 3 different repositories, then I don't know how you can easily push a change from dev to staging and to production.
I would tend to go for the 3 branches.
What is concerning is that you said:
if we maintain a single repository the individual developer would get access to complete production codebase and he would be able to commit the changes to master branch
That sounds to me like there is a trust issue with the developers. I'm sure you can use some sort of permissions to limit who can check in to master. If you use Git, I think that you could have your devs doing push requests to master. You could then have a 'trusted developer' to review and accept those push requests into the master branch.
I don't know much about git permissions so once you've designed your strategy, you could ask elsewhere for the implementation specifics.
Hope it helped
It will be a best practice to have one repository for your project rather than for your Sandbox. While your project moves across various stages , your code will flow across multiple branches and get ready for go-live.
It is good to write your own script to filter and include metadata components since some metadata components like Flows , Documents, profiles are not as simple as they appear in API guide. GITHub doesn't have branch level permissions. BitBucket has it. So, if you are using GITHub, best way is to one tightly controlled repository with all the branches and one public repo which developers can work and commit. The merges from Public repo to secured repo has to be managed internally