<Patrick.Higgins@xxxxxxxx> writes: > I am trying to get my employer to start using git and have found the > distributed model and git's branching to be one of the hardest parts > to explain and understand. Take a look at description of version control and distributed version control at BetterExplained, and slides from presentations / seminars which you can find in GitLinks page at git wiki. > I put together the attached diagram (done with graphviz so some > things are not in the most logical place) to help explain things to > my coworkers. > > Unfortunately, I don't understand things well enough myself to know > if the diagram is correct or not. I read in the stgit docs that > developing directly in the master branch is discouraged by > convention, but I don't really understand why. The git tutorial > shows work happening directly in master, so I wasn't sure if that's > a convention that only makes sense for stgit or for plain git, too. > > Does my diagram make sense? Are there any suggestions or corrections? It is much too complicated. IMHO it would be better to explain the idea of remote branches first (separate diagram), then simplify diagram by showing only relationships between repositories: relationship between branches is impled. Perhaps adding what branches are supposed to be found at given repository... BTW. do all transfer is pull (or fetch) only, or are there pushes and exchanging patches via email? > In my diagram, I am assuming that most developers work in master, > and make branches for their own long-lived projects and experimental > things. For example git itself, as a project, uses three long-lived branches: 'maint', 'master' and 'next', uses 'pu' (proposed updates) branch as propagation / review mechanism for short-lived tipic branches. -- Jakub Narebski Poland ShadeHawk on #git -- 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
