对于git相信大家都不会陌生，或多或少都会用过版本管理工具，如：svn.........等。在这个全民编程的时代，github已经不只是程序员的聚集地，而成了一个大众的网站了，只要有一点编程基础的同志都能在github中找到自己的一个天地，所以作为github官方指定版本管理工具git就不能不了解下了。
本文适合有一定git使用经验但是对git没有清晰的概念的同志，我来列举下自己使用git的时候需要明确的几个概念。如果你没使用过git，以下这篇文章能帮助你快速入门：
https://www.runoob.com/manual/git-guide/
(算了，不废话了，当时写给自己的tech review啦，相当于点舒服点写啦)
以下为大纲
1. 相比起其他的版本管理工具，git其实没有权限管理
link :https://www.zhihu.com/question/22363313 以下为总结摘录 :
GIT的权限管理是说控制用户能不能PUSH或者DELETE分支，或者能不能PUSH代码，而不是能不能访问某个目录的文件。
（就使用github或者gitlab 来讲,吊，其实两者都一样都使用说明都差不多，起码这部分系差不多我就着重挑github来讲
吊，就这PART我都可以写比啊边个啦 ）
以下在操作基本在github上实现，不过gitlab上也差别不大.
说到权限就要从协作讲起
1.基于仓库的协作：
- 同一账户协作： 一个账户多个人员使用，不分彼此，这里演示配置SSH登录
主要分两种模式：
- contributor 模式： 每个合作者在他们fork的仓库上进行代码修改、发布自己负责的部分，再向主仓库提起pull request
- collaborator 模式： 每个合作者新建自己部分的feature branch，在这个新分支上进行代码修改，然后提起向master branch的pull request
贡献者模式：
B都需要fork A的项目仓库，从而在B的主页上得到A的代码仓库的一份拷贝；然后B需要将该仓库clone克隆到他的本地硬盘上去成为本地代码库再进行后续修改。此时，在B的本机上得到的是主分支，即master分支。
为了进行开发，B可以选择在本地新建一个其他分支并在这个新分支上进行开发。使用命令：git checkout -b new_branch创建并切换到新分支“new_branch”。
然后在这个新分支下进行代码修改和开发。
写好代码后，需要推送到远端，可使用命令：git push origin new_branch。这个命令省略了远端分支名，由于该名称的远端分支并不存在，故会新建一个名为new_branch的远端分支，然后将本地代码推送到该远端分支。此时在B的github主页上(即远端)可在Branch下看到有两个分支，一个名为master，一个名为new_branch。
此时，所有的代码修改都是在B的本地和远端的new_branch分支下保存的，可将此修改提交到原仓库(A的master分支上)去。可在github主页上点击Compare & pull request命令，此时会弹出一个Comparing changes的页面，可对B：new_branch和A：master两个分支下的代码内容进行比较并创建pull request。如下图：
注意：在上图中，可以对被merge的仓库和分支进行选择，比如这里，如果B仅仅想把new_branch分支融合到B自己fork了的项目的master分支上，而非A的项目分支上去，就可以在上图左边点击下拉图标进行选择。
说明：为其他分支来开发？
——其实在这里有两种选择：1）在本地new_branch分支上写好代码后，先在本地merge到master分支上，再将本地master分支push到远端master上去；2）在本地new_branch分支上写好代码后，先push到远端成为一个新的远端new_branch分支，然后提起pull request，然后其他人可对其进行审查，觉得可以的话，再同意将远端的B：new_branch分支merge到远端的A：master分支。
即便是A自己向自己的项目master分支提交代码也应遵循这一工作流程，即先在本地创建new_branch分支，然后push到远端成为一个远端的new_branch分支，然后提起pull request，在其他人审查合格后再将自己的远端new_branch分支merge到自己的远端master分支。
在B创建了pull request之后，A(owner)会收到相关提醒，提醒B作出了某某提交。当然，如果B本身也是项目的合作者的话，那么他自己就能决定是否merge该pull request，而不必经过A的允许。
合作者模式：
假设我们有两个合作者A和B共同开发维护一个代码仓库(repository)，其中A是仓库的拥有者，他可以为项目添加合作者。
A在他github项目主页的Settings——Collaborators里面进行添加，邀请B为合作者。B在收到邀请提醒后，可选择接受邀请。B此时拥有了A所创建项目的直接读写权利。
注意虽然此时B已经是该项目的作者之一，但此时在B的github个人主页上不能看到该项目的repository，因为这个repository并不是B所拥有(创建)的。可以在B账户的setting下的repository部分查看 https://github.com/settings/repositories，或者点击github主页面也可看到https://github.com/。
collaborator模式适合用于一个小型的、信任度较高的团队中，因为此时几个合作者都拥有了最高“写”权限。这种模式下，不需要像contributor模式那样让每个合作者对原仓库进行fork，而是可以把这几个合作者看成一个人在工作，遵从git flow的方式，从而以创建不同branch的方式进行合作开发。事实上，在最早的git中branch和fork间区别并不大，所以对于一个高度互信的小型团队。利用branch特性来进行合作开发就足够了。
B访问到A的项目仓库后，可将其项目克隆到自己的本机上，然后在本机上进行开发。开发时，为了便于代码审查以及防止冲突，应另开分支再开发。比如新建自己部分的feature branch，在这个分支下开发好后，可直接push到远端，注意此时会直接推送到A的项目仓库下，因为B作为合作者拥有A创建的项目的直接“写”权力。
此时查看A的项目主页，会提醒你最近push了一个branch到该仓库下，你可以选择Compare & pull request，从而试图将你在新分支下所作的代码修改merge到该项目的master分支上去。如下图所示：
如果一切顺利的话，点击Compare & pull request之后会提示“This branch has no conflicts with the base branch”.说明新分支可以被顺利融合到主分支上去。如下图所示：
由于你(B)本身就是项目合作者，所以拥有权力决定是否批准该pull request。如果你觉得可以的话，就直接点击Merge pull request，从而使得新分支内容merge到主分支上去。
可见，以合作者模式开发项目代码时，仿佛你就是该项目的创建者，你拥有最高权限。
就是仓库层面可以进行pr
单纯的pull和request
1.setting -->deploy keys
生成ssh 密钥进行用户登录，缺点：登录是同一个用户就是就sshkeys的添加者，前提是需要有这个项目的push权限或者成为成为仓库的coropoerator(合伙人)
2. 为分支（branches ）配置保护规则 ： 例如 force push reset and rebase even deletion
setting --->branches ----->branch protection rules --->add rules
其中需要注意的是，
branch name pattern 配置的不是这个rule 的名称 而是这个rules适用branches 的匹配规则
关于模式匹配语法可以参考 https://help.github.com/cn/github/administering-a-repository/configuring-protected-branches
总体就是使用 * 通配匹配和 / 来描述层级。
3.邀请某人成为这个项目的collaborator
基于team 和organization
注：如果希望项目既有collaborator同时又可以限制他们的读写权利，尤其是限制其“写”的权利，可利用organization来为team成员赋予不同等级的权力。详见github中organization的相关操作。
4.这个过于复杂，我就不详细讲了就放个link自己看吧：
以上总结可以看这个link
）
对目录和文件的可读是GIT的最基本要求，不可能做到针对目录级别的不可读
唯一可行的就是多建立几个独立库，然后用外部引用的方式弄到一个总的GIT库里。再独立库里面做用户的分配
但是GIT不能支持某个目录下面单独指定文件的不可读，所以你要是做复杂读写权限控制，除非一个愿意细化到某些配置文件就独立开库并指定用户，否则别找虐了。
你要的就是集中式的管理，用GIT干嘛呢？
从技术上将，Git可能永远也做不到类似SVN的路径授权（读授权）：
• 如果允许按照路径授权，则各个克隆的关系将不再是平等的关系，有的内容多，有的内容少，分布式的理念被破坏
能深入下
• 如果只有部分路径可读，则克隆出来的提交和原始提交的提交ID可能不同。因为提交ID是和提交内容有关的，克隆中提交的部分内容被丢弃，势必提交的ID也要重新计算
不懂......
• 允许全部代码可读，只允许部分代码可写，在版本控制的管理下，是没有多大实际意义的，而且导致了提交的逻辑上的不完整。
那么有什么办法来解决授权的问题？
1. 公司内部代码开放。即代码在公司内部，对项目组成员一视同仁的开放。
评：想太多了；
2. 公司对代码库进行合理分解，对每个代码库分别授权。即某个代码库对团队成员完全开放，对其它团队完全封闭。
普遍的用法
3. 公司使用Subversion做集中式的版本控制，个人和/或团队使用 Git-svn。这样在无法改变公司版本控制策略时，程序员可以采用的变通之法。
4. Git服务器的部署实际上可以使用钩子对分支和路径进行写授权，即可以控制谁能够创建分支，能够写特定文件。
2.git是由linus之父开发的，所以最能体现git的概念操作界面应该是命令
3.基于2，虽然最好是使用git命令行（如gitbash）来操作git，但其实图形化的界面更有效率，更能体现清楚的帮你意识到当前的状态（以下为各个软件使用功能的对比图）
4.好像没了..
637
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
