[Patrick: apologies if you get this twice; the first time I did "reply" instead of "reply all" and it only went to you, not the list.] On Thu, Apr 17, 2008 at 10:30 PM, <Patrick.Higgins@xxxxxxxx> wrote: > Does my diagram make sense? Are there any suggestions or corrections? Looks ok to me, but I'm still learning git myself... so beware of what I say :-) Some quick comments: The Project repo (the big one in the middle) need not, I think, maintain long-lived tracking branches for every developer. Rather, that repo would pull based on outside-git inputs (analogous to emails saying "please pull from ...") and there might be a temp tree created to test stuff out but once the merge or cherry-pick into the local master is done that temp tree would disappear However, if you don't have too many devs then your method is fine too. The problem with devs working on the same branch that the project repo pulls is that the commits may have some cruft, even though you said they'd make branches for experimental things. The way I'm working now, my "master" is clean as a whistle and anyone pulling from it and merging gets exactly what is needed. Again, this is not a rule, but personal preference and if your style of working is very clean then this may not be needed. Regards, Sitaram -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
