We have been using SVN for long and the main reason is that it allows us to restrict access to different branches of the repository to different developers (Thru the authz file).

SVN is simple to understand and a few commands are all we need and has served us well over the years.

But I often wonder if it is a case of "ignore is bliss" that we have not moved to GIT when the whole world appears to be doing just that.

In Git, is it easy to allow limited access to the repository so that the developer cannot even checkout, let alone commit, branches he is not provided access to? In short, can the functionality in SVN available thru authz file possible in GIT?

We do encounter conflicts occasionally in SVN commits which can be a bit of a pain to handle. Does Git handle such conflicts better?

In an enterprise environment, where repositories are all private and access is limited to a subset of all developers, is SVN a better choice in terms of simplicity?

CodePudding user response：

The only way I can think of restricting developers access to branches would be to create multiple remotes for the same repository. That way it would be possible for someone to work on a branch on "restricted-origin" which only a few developers have access to.

It would have to be pushed to the normal origin sooner or later though since it has to be merged.

If you only care about restricting making commits (or rather pushing) to a branch, then that is a feature supported by most git hosting services.

I'm afraid I can't be much help in the comparison between SVN and git, it has simply been to long since I used SVN last.

CodePudding user response：

As IMSoP notes in a comment, the question as phrased can't really be answered, but the embedded question can:

Q: Does Git have a way to keep people from reading particular committed files, via some access control mechanism?
A: No.

That's all you need at this point: the capability simply doesn't exist—not in Git as implemented, and the design of Git makes this exceedingly hard to achieve at other levels, so that you generally won't find it in most Git hosting services either. If you find some hosting service that does claim to offer it, be suspicious that their claim is at best overblown and that there are ways around it. That's not guaranteed, but they'd have to have a very non-Git-oriented way to get at things, to provide a proper hermetic seal.

There is a related question:

Q: Do branches actually exist in Git?
A: No—not the kind you mean with SVN, anyway.

SVN branches have real substance to them. (This is what makes them somewhat expensive to create, vs Git's super-cheap "branch" that costs just a few bytes.) Git's notion of "branch" is very different. There are totally-ephemeral analogues, which won't get you anywhere because they are ephemeral, and things that Git also calls branch that are unrelated to what you're thinking, which won't get you anywhere because they're unrelated.