On Mon, 7 Nov 2016 08:16:26 -0800 (PST) David Karr <[email protected]> wrote:
> 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. I'd say it's a bold statement. Or may be you're too freely mixing Git and Github (or something like this). The thing is, every (non-shallow) clone operation is technically a fork because all Git repositories are free-standing. But I sense that you're using the term "fork" to refer to a fork-as-on-github sense: that is, you "copy" a repository "on the server" and then clone it, not the original. If yes, please note that you're really confusing matters for yourself: that's not how Git works. That "forks + pull requests" thing was developed by Github (or may be copied from somewhere, I dunno who'd pioneered the approach) basically as a means of adding "social" feature to their service. Absolutely nothing in Git itself requires of favors this model of development. (BTW the term "pull request" existed before Github appeared, and meant something else.) As an example, the Git devs do not use Github for development, and hence they don't have "forks" and do not use Github-style "pull requests". To say that in more broad terms, Git has several core concepts which you can't go against (say, you can't push/fetch less than a complete commit and stuff like that) but as long as you don't go against the grain of such "core foundations", how you do structure your work, is completely up to you. To continue with examples, in my organization, "central" (i.e. "reference", "rendez-vouz" etc) repos are hosted using gitolite and are created by a dedicated administrator. This means the devs have no physical way to "fork" except for hosting their own "fork" (meaning here a remote repository they synchronize with) somewhere on their own premises. But they simply don't need that because they have "personal branches" in the single central repository of a particular project. Say, if a developer needs to work on some feature X, they create a branch in their local repository and then periodically push it into a branch named with their prefix in the central repository. Say, it might end up being named "abs/feature-x" for a developer whose names' initials are A.B.S. This thing work quite nice for us. Say, on our current project, I have an integrator, who, from time to time, gets asked by different devs to integrate their work done on such and such branch(es), so he fetches those branches down, merges them fixes breakage, verifies the project did not fell apart etc -- the usual routine. Say, for him to integrate that abs/feature-x branch would amount to git fetch abs/feature-x # to get it. git log origin/abs/feature-x ^develop # to see what's there. git checkout develop git merge origin/abs/feature-x ... git push origin develop That's just one approach. Others are surely possible and do exist. Just to stress your world view, consider that it's not even needed to have a dedicated centralized repository: provided the computers of all the developers some connectivity Git can use (say, SSH or CIFS shares), it's possible to exchange pieces of work completely in decentralized manner. Of course, having centralized repos is not plain cargo-culting things of distant past but they do carry much mental baggage from the centralized VC systems for sure. Git does not _need_ them and so it does not need Github-style forks. > 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. I'd say you just got slightly fixated on that apparent Github-ism which is not at all essential. Hope I managed to explain why. ;-) Note that different things may be in play here. Say, we have a very small team, and so we have very small administrative burden -- for instance a possibility of someone messing someone else's branch is next to zero (I'd say it's practically zero by all means), but if you have a few dozens or more devs, things may start to get out of hand, and you'd need to implement better barriers. Maybe Github-style forks might help here, I have no idea. I would also recommend reading [1] not as a guide to follow but just as a way to get a "big picture" view of how Git was envisioned and for which it was created. 1. http://lwn.net/Articles/246381/ -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
