适合开发人员和设计人员团队的最佳 git 工作流程
我们将使用 MVC 框架开发一个 Web 应用程序。我们的团队中有开发人员和设计师。我们想使用git。有没有办法让设计者只能看到项目的某些目录？ （意见）。我不希望设计师查看并意外更改视图以外的其他文件。
We are going to develop a webapp with a MVC framework. We have developers and designers in our team. We want to use git. Is there any way designers could only see some directories of the project? (views). I dont want designers loking and accidentaly changing other files than views.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
可能的选择之一是使用 Git 子树 （或子模块，但我个人不喜欢它们，请参阅链接问题以获取原因列表）。将视图放入单独的 Git 存储库中，并将其作为开发人员主存储库中的子树拉出，设计人员无法访问该存储库。
或者将所有内容保留在一个存储库中，但拒绝设计者用户在预提交挂钩（和/或服务器上的预接收挂钩，如果您偏执的话）中对 M 和 C 部件的任何提交。
你也可以使用Git进行稀疏结帐，但我个人认为其他两种解决方案更实用。
One of the possible options is to use Git subtrees (or submodules, but I personally dislike them, see linked question for a list of reasons). Put views into a separate Git repo, and pull it as a subtree in developers main repo which is not accessible to designers.
Or keep everything in a single repo, but deny any commits to M and C parts from designer users in a pre-commit hook (and/or in pre-receive hook on server if you're paranoid).
You may also do a sparse checkout with Git, but I personally think that other two solutions are more practical.
为代码和设计人员制作两个不同的存储库。您还可以使用 子模块 对子项目进行分组并一起跟踪它们；但我没有使用过，所以我无法给出任何具体提示。
另一方面，如果您采用“git 风格”的方式来设置存储库（例如，每个用户都有自己的存储库的私有公共镜像；每个人都具有读取访问权限，但只有所有者具有写入访问权限。如果您想要，一个规范的（主/主干）存储库，如果您想要只有受信任的开发人员具有写访问权限）意外修改应该不是一个大问题。您可以从设计者存储库中提取内容，看看它是否有意义并纠正错误，然后再将其合并到“规范”主分支中。
Make two different repos for code and for designers. You could also use Submodules to group the sub projects and track them together; but I have not used that so I cannot give any specific hints.
On the other hand, if you adopt a "git style" way of setting up the repositories (e.g. each user have their own private public mirror of their repository; where everyone has read access but only the owner has write acccess. And if you want, a canonical (master/trunk) repo if you want where only trusted developers have write access) accidental modifications should not be a big problem. You can just pull from the designers repo and see if it makes sense and correct errors before merging it into the "canonical" master branch.