> I'm working with a team that is new to git.  I'm not "new" to git, but I 
> wouldn't describe myself as an expert.  However, I've used almost every 
> popular SCM tool that came before, since there were SCM tools.

> Their original process was very primitive, simply committing and pushing 
> directly to master, all in a single remote repo.

> I'm moving them towards a better process in steps.  This week I'm 
> transitioning them to creating feature branches and pull requests.  I haven't 
> advised them to have each developer fork the main repo and create the feature 
> branch from that fork, I'm just having them create the feature branch from 
> the main repo.

> I'm well aware that in large-scale open-source development, the fork approach 
> is the only reasonable way to work.

> What I'd like to hear is clear and objective arguments for when the fork 
> approach is critical, and when it might not be that critical, in the context 
> of an internal commercial project.

Hi David,

Some thoughts: You don't say how big the team is or how busy the changes are, 
and if they overlap, which is a question about how much coordination is needed 
(can they self coordinate?).

If the team were to use a fork based approach, then you should be providing the 
fork server (obviously?), A fork based approach allows the individuals a level 
of freedom to try stuff without cluttering the golden repo. When the OP branch 
is looking reasonable it can be pushed up (on a branch of its own) to see if it 
integrates OK. You will still need a coordination mechanism (e.g. see Git's own 
master-next-pu approach)

Even if you do not use forks, you will still need a local branch naming 
convention, so that you can tell whose is whose. You will also need a method 
for deciding how to purge other folks rubbish (which they may disagree about...)

Philip

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to