4

I am trying to clear my confusion about how to work with more than 1 developers on a git repository. Let me explain how we worked till now.

We have 3 developers working on a same project lets say dev1, dev2, and dev3. Master branch on a git server and that is checked out, what we do is, when a developer clones the repo for the first time, he creates a new branch lets say branch-dev1 on his local machine, and he works on that branch. And when things look stable, he pushes his branch to central repo. So his branch branch-dev1 is available in the centralized server. A project manager, then merges his brach to the master branch, and resolves conflict if there is any. Similarly dev2, dev3 pushes their branches branch-dev2, branch-dev3, and again their branch is merge and conflicts resolved if any. Then the next day, each one of them pull the head from the centralises server and gets the commits from other devs. And they work in iterations.

What I want to know is, is this the correct approach?

Nitesh
  • 702
  • 2
  • 7
  • 22
  • GIT: When dev1 cloning the repo he gets (surprise!) his own branch. It's called master for dev1 and origin/master is the branch on centralized server. When developer pushes commits to centralized server these two branches merges. But you can have many branches on centralized repository and developers can push their commits to these brances. – Sergey P. aka azure Feb 23 '12 at 14:51

2 Answers2

3

One of the confounding things about git is, there IS no "correct approach".

Git is a DVCS. It could also be called a "workflow toolkit". It enables you to set up and create whatever workflow works for you.

If separating contributions to the main line of development by developer makes sense for your organization, then do that. There's also no problem with multiple developers all working on the same "development" branch. Or with separate little branches for separate features each developer is working on.

Dan Ray
  • 21,623
  • 6
  • 63
  • 87
2

It is important to know what upstream means with a DVCS.
See "Definition of “downstream” and “upstream”".
Once you know that, you realize you can have many upstreams repos.

You have only describe one of the possible workflows, as described in "Distributed Workflows (Pro Git book)":

centralized distributed workflow

This isn't the only one (as shown by the rest of the Pro Git page), and doesn't prevent dev1 to register dev2's repo as a new upstream (remote) repo and fetch directly from there.
However, if the three devs are working on the same "development effort", they should work (or at least push to) the same branch: see "When should you branch?".
Don't forget that, with a DVCS (Distributed VCS), the concept of branching is orthogonal with the publication (push/pull).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250