2009/8/28 Abhijit Bhopatkar <bain@xxxxxxxxxxxxxxxx>: > Hi, > > After a long pause in the development, i am back to drawing boards for teamGit. > > Ever since i adopted git as my preferred version control system for my > teams, I had this tough time keeping up with every one. Of course this > is a GoodThing(TM) since this means pace of development is rather > good. But it has its usual problems of forcing everyone to religiously > publish _AND_ keep rebasing on main branch every so often. Also my > major problem is that we discover conflicts only _after_ a developer > tries to rebase his work, typically (by design) after he has fully > coded and tested a feature. What sort of time frame are you talking about? How long are your sprints, or however you partition your work. I can't help but feel the problem should be solved elsewhere. Do you have daily scrums? Everyone should know, roughly, what everyone is doing. If you are using 2-3 week sprints (or however you partition the time) and everyone is roughly aware of what everyone else around them is doing, there shouldn't really be so much of a problem. > The current way to get around this is shouting aloud before you start > working on a new feature/file/section. How do you allocate the features in the first place? At the start of a sprint? If so, it should be the person in charge of that that should see if there are going to be conflicts. If you don't have sprints, then how do you divide up tasks? John -- 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