1

I am currently the lead of my site's dev team (3 people) and we are looking into ways to incorporate git into our daily work flow.

Some requirements:

  1. The site must have 1 main repos. Everything commited to this repos must be approved by me only.
  2. Everyone works in their own computers. They will need to pull from the "main repos" make changes and then resolve conflict if they want to push

Let say there are 3 people in my team, A (I am A btw), B and C. A possible solution that I have come up with (but is kind of hackish and slow overall):

  1. There will be the following repos: reposA, reposB, reposC, and reposMain
  2. When B wants to start work, B pulls from reposMain to reposB, does work on reposB, and commit to reposB.

  3. So when reposB thinks it's good, it merges that new_branch to reposB's master, and tell me to ssh into reposMain and pull from reposB/new_branch to reposMain/reposB_branch

  4. All the conflicts pulled to reposB_branch would have been solved by then, then I do a diff and see if I like the change, if I like it, I will merge that into reposMain's master

  5. Everyone pulls from reposMain when they start their workday.

For this setup, I would need to make reposMain downloadable(readable) to all my team but make it non writable to them (that can be done with chmod). The only down side is that this is a really hackish solution and requires me to explicity ssh into reposMain and do the merging etc.

Are there any errors/problems that you see with this workflow? Is there a better solution than this?

xjq233p_1
  • 7,810
  • 11
  • 61
  • 107

2 Answers2

4

Are there any errors/problems that you see with this workflow?

Umm, your inadequate faith in your coworkers? Given that this is a "small startup" I don't really understand the need for you to personally review every commit, but even taking that as a given, shouldn't it be sufficient just to tell them what the commit policy is?

My greater familiarity with subversion may be biasing me here, but I think it will be more practical if all three of you can write to the repo. Often you're going to code-review something by standing over their shoulder and having them walk through it while you stare at their screen. If it looks good you'll just want them to commit it then and there.

And heck, maybe they'll find and fix bugs in your code if you let them!

Robert Calhoun
  • 4,823
  • 1
  • 38
  • 34
  • I think you do have some bias there. Even with subversion, I'm sure it's quite common not to let everyone commit directly to the official stable trunk (or whatever it's called). This is the same kind of restriction - don't let everyone push to the central repo's master branch. There's no need to give them write access to the central repo at all, since they can just work within their own repo (unlike subversion). – Cascabel Nov 06 '10 at 04:41
2

For your machine, you'll use git remote add to tell git about all the repos. When someone wants you to incorporate their changes, you can do git fetch reposB, examine the changes, and do git merge reposB if they look ok. Once ready on your computer you'll do git push to send to the shared repo. Shouldn't need to do any explicit SSHing.

For a more in-depth discussion see Chapter 3 of the Git community book.

Brad Mace
  • 27,194
  • 17
  • 102
  • 148
  • quick question: if that's the case, that means that I must create a git account where 1) it has read access to my repos, 2) but not write access to my repos. Is this kind of configuration safe? Will user B pull directly from reposA instead of the reposMain? (thus I can eliminate the existence of reposeMain?) – xjq233p_1 Nov 06 '10 at 04:02
  • I'd assume you'd use git over ssh for writing (specified when initially telling git about other repos). For read only you can use the git server (uses `git://` protocol). You can have the other users refer to your repository and leave out the separate master if you wish. – Brad Mace Nov 06 '10 at 04:08
  • If it's on a local network you could conceivably use mounted directories or SSH for everything, letting the file permissions take care of making one user's repo read-only for everyone else. – Cascabel Nov 06 '10 at 04:42
  • Should probably check out this question before deciding to go the network-share route: http://stackoverflow.com/questions/750765/concurrency-in-a-git-repo-on-a-network-shared-folder – Brad Mace Nov 06 '10 at 04:44