笑话哦本文目录一览：
- 1、GitHub 是怎么火起来的
- 2、github一些好用的第三方
- 3、漫话：如何给女朋友解释什么是Git和GitHub
- 4、github是陷阱吗
- 5、github的pull request是指什么意思
GitHub 是怎么火起来的
Github不是突然火起来的，在Ruby社区Github其实从一开始就很流行，我们2009年搞Ruby大会就邀请了Github的人来上海了，早在2009年Github在国内的Ruby社区就很有名气了。之所以今天大家突然觉得Github火，只不过是因为刚拿到1亿美元融资的眼球效应罢了。
Github是一个从Ruby社区诞生出来的项目，这几年我也算是看着Github发展起来的，可以说Git在Ruby社区普及和爆发几乎是必然的事情。Git虽然是Linux内核社区开发出来的，但前几年一直不温不火。真正在开源社区普及和爆发，是从Ruby社区和Github开始的。
Rails是一个高度集成的Web框架，通常情况下一到两个Rails程序员做一个Web项目就够了，一旦多人同时在一个Rails项目上工作，代码提交和协作会遇到很大的麻烦，更不要说开源项目大规模远程协作了。这算是Rails项目的一个痛点：单个工程师开发效率很高，但是团队协作很困难，CVS/SVN这种集中提交式的SCM都不能很好的支持Rails团队的工作模式。事实上我的Ruby团队规模一大也遇到了这个难题，代码提交经常冲突，协作困难。
Git这种良好支持分支管理的分布式的SCM真正解决了这个问题：每个工程师在自己本地分支上开发，完成功能以后往master分支合并。我们Ruby团队使用Git以后，代码提交冲突问题迎刃而解。所以Git这种SCM像是给Ruby社区量身打造的一样，所以你可以看到Ruby社区几乎没有不用Git的。
Github本身也是这种需求下的产物，一些湾区的Ruby社区的程序员使用Git以后，找不到好的Git托管网站，于是就开发了Github出来。然后Rails框架率先迁移到Github上，形成了示范效应，整个Ruby社区呼啦啦都迁上去了。Ruby社区另有一好处：各种开源库和包都统一用Gem格式发布，而一旦大量Gem都迁移到Github上了，Ruby程序员就跟着都开始用Github了。我当年就是为了跟一些gem的库就开始用Gihub的。
这里多说两句：Ruby社区是一个相当团结的社区，很少分裂，经常是一旦采用一个技术，整个社区就会迅速跟进和普及。虽然在国内Ruby是个小众的编程语言，但是在硅谷，Ruby很火，被誉为云计算时代的Web编程语言。Ruby整个社区都迁移到Github，开始对其他编程语言社区形成示范效应，其他编程语言社区接着跟进。
Ruby程序员因为做Web开发，经常用JavaScript，很多Ruby社区核心人员本身也是JS社区的核心人员，JS社区也就很快进驻Github。同时Ruby社区因为DHH的示范效应，基本上整个社区都是人手一台Mac，天然对OSX比较近，而随着iOS开发的繁荣，大量的Ruby程序员跟进开发iOS app，带动iOS社区也从Github上成长起来了。看看今天的Github，Ruby，JS和iOS的项目比例是非常高的，Java比例则远不如Sourceforge和Google Code，这有一定的社区渊源。
Github也很重视社区活动，经常搞Drinkup，此外Github产品上有很多领先的地方，例如从网站产品上定位为social coding，支持大规模开源项目分布式协作的各种工作模式等等。
不过Github现在估值这么高，我认为主要还是云计算SAAS平台的概念带来的，它给企业用户提供Private代码仓库托管收费服务是盈利的。云平台现在估值都很高，Dropbox，Evernote都远比Github估值高，所以Github现在的估值高也不算意外。
github一些好用的第三方
1.
2.
1.
2.
1.
2.
3.
4.
点赞动画
动画按钮
分类大全
1.
2.
自定义3D 转场
限制高度的textview
低耦合集成TabBarController
漫话：如何给女朋友解释什么是Git和GitHub
来自：漫话编程
周末，我正在家里看《最强大脑》，女朋友在一旁刷手机，相安无事。谁知道，刚过了没多久，她突然问我：
版本控制
想要介绍什么是GitHub，就要介绍下什么是Git，想要介绍什么是Git，那就不得不提版本控制。
我们知道，如果多台计算机在同一个局域网中，是可以进行局域网文件共享的。共享者可以通过设置把自己文件共享给他人进行阅读和修改。
对于同一份共享文件，如果又多个人需要修改的话会发生什么事情呢？假设现在有三个人，A分享了文件夹mhcoding，其中包含了三个文件mhcoding1.png，mhcoding2.png，mhcoding3.png，B和C需要对这份文件进行修改。
B和C分别把mhcoding文件夹拷贝到自己的电脑上，然后进行修改，改完之后需要再把自己修改上传上去。B先改完了之后把自己的文件上传上去，覆盖了A的分享。之后C也改完了，也把自己的改动上传上去。这样，C就会把B的修改覆盖掉。
为了上述这种问题，就需要通过一种方式来在C想要上传文件的时候来提醒他，告诉他需要考虑到B已经改过文件的事情。
比较好的方式就是通过版本控制。
如果使用了版本控制系统，每一个团队成员都可以在任何时间对任何文件毫无顾虑的进行修改，版本控制系统可以提醒我们文件修改冲突，甚至可以帮我们自动把多个人的改动合并到一起。
有了版本控制，我们还可以回溯查看以前某一个版本中具体文件的内容，还可以查看某一次改动的变更内容。非常适合团队协作。
版本控制的方式
本地版本控制系统
许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单。不过坏处也不少：有时候会混淆所在的工作目录，一旦弄错文件丢了数据就没法撤销恢复。

为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。

集中化的版本控制系统
接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？于是，集中化的版本控制系统应运而生。
这类系统，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。

这种做法带来了许多好处，特别是相较于老式的本地版本来说。现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限，并且管理起来也轻松容易的多。
分布式版本控制系统
集中化最显而易见的缺点是中央服务器的单点问题。如果中央服务器宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。
要是中央服务器的磁盘发生故障，碰巧没做备份，或者备份不够及时，就会有丢失数据的风险。
于是分布式版本控制系统面世了。在这类系统中，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的提取操作，实际上都是一次对代码仓库的完整备份。

Git
git其实就是一款我们前面介绍的分布式版本控制软件，Git具有以下特点：

程序员是比较典型的需要团队协作的职业，大多数情况下，都是需要多个程序员同时开发同一个项目的，就好像多个程序员要同时修改一份word文档一样。所以，Git是很多程序员的必备工具。
GitHub
GitHub是一个面向开源及私有软件项目的托管平台，因为只支持git 作为唯一的版本库格式进行托管，故名GitHub。

所谓托管平台，也就是说他可以用于存放文件。只不过上面的文件都是可以公开被访问到的。
GitHub是通过Git进行版本控制的软件源代码托管服务，并且，GitHub还引入了一些社交属性。号称是世界上最大的程序员（同性）交友网站。


GitHub上那些奇葩"项目"
Dress - 女装大佬聚集地
有129名贡献者在这个名为Dress的项目里集结，上传了数千张女装照，收获了8000余颗星。

你敢相信这是个码农？
地址：
Thanos - 灭霸命令
Thanos.sh是一个开源的个灭霸命令，可随机删除电脑上一半文件。

地址：
nocode - 一行代码都没有
这是一个Issue比项目更精彩的项目，项目中一行代码都没有，Issue中各种装逼。

想问下，Star这个项目的2.7万人是有多无聊？？？
programmer-job-blacklist 码农找工作黑名单
hangzhou_house_knowledge 杭州买房攻略
howmanypeoplearearound 通过 Wi-Fi 信号估计附近有多少人
github是陷阱吗
放弃使用Github吧!

Ivon Huang
Linux及自由软件爱好者。
老子说：千里之行，始于足下。
这边文章讲述了Github的缺点，以及为何应该拒用Github。
Give Up GitHub!
原文网址：
作者：软件自由协会 (Software Freedom Conservancy)
原始文章授权：CC BY-SA 4.0
翻译： Ivon Huang
我们知道这并不容易，Github无处不在。在他们成功的行销之下，Gihub向FOSS (自由和开源软件) 开发者证明了这是最佳 (也可能是唯一) 的FOSS开发平台。然而，作为含有专有软件，商业秘密工具的平台，Github的理念与FOSS精神恰好相反。相较之下，Git当初就是开发用来取代专有软件"Bitkeeper"的，并且能分散式的开发FOSS的软件，去中心化，不依赖中心站点。 Github将Git包装后，加入一些扩充功能，让原本分散、平等、FOSS的系统成为中心化、专有的站点。并且，那些扩充功能皆是由单个营利公司所控制。现有的FOSS开发社群使用Gihub，让新来的开发者加入这个专有平台，让Github名声渐广，同时也限制了下一代FOSS开发者的眼界。
我们知道很多人每天都会依赖Github。要放弃使用随处可见、免费、有用的工具是很难的，即使他是专有软件。对软件开发者来说，弃用Github可能比弃用Facebook还难！我们不会责怪正在挣扎的你，但是我们希望你可以读读看下面关于放弃Github的理由，以及寻求更好的替代品方案。
并且，请偶尔回来看这篇文章，我们会继续更新相关内容。
1. 为什么要弃用Github？
有很多放弃Github的理由，但下面我们只列出最重要的：
Copilot是营利工具
Copilot是由微软和子公司Github所开发的工具，使用AI自动生成代码辅助开发者。按照Github官方声明，AI模型是使用Github上托管的专案所训练，包含使用著作传授权条款的专案。这些专案可没有进入公有领域，而是使用FOSS授权条款发布的。这些条款要求适当的标注作者，有些著作传条款还会要求以该专案开发的软件必须使用同样条款发布。这一年以来，微软和Github长期无视这些条款。他们唯一做出的辩护是前Github CEO发的一条推文，认为该领域已有相关法律规定，属合理使用。然而这是错误的，该领域尚未立法。除了法律问题外，Github使用著作传保护的代码来开发专有软件，其中有严重的道德问题存在。
与美国移民局的关系
2020年，社群成员发现Github与美国移民局(ICE)有签订营利性质的软件服务合约。社运人士和Github员工二年来不断呼吁Github取消此合约，但Github却回覆，母公司微软多年来都向ICE贩售Microsoft Word，也不见有人抱怨。他们宣称很多企业都跟政策有问题的机关做生意。不论你对ICE的观感如何，Github对重要议题的轻蔑和不诚实，再再证明了Github将公司营利置于社群意见之上。
假装支持FOSS软件
即使Github一直假装他们支持FOSS软件 (就像前辈SourceForge一样)，但他们的托管网站完全就是专有软件和商业软件组成。我们很感谢Github让他们员工偶尔贡献部份FOSS专案的上游源码，但社群已经被Github伤害太久。他们宣称支持FOSS软件，却要求社群依赖他们的专有软件。我们不能再让Github这样欺压下去了！
不提供自托管选项
Github跟同类FOSS专案托管公司的最大不同在于，他们没有提供自托管的选项。他们所有的代码都是不公开的。举例来说，我们在批评Gitlab的商业运营模式时，讲到他们提供「社群版」和「企业版」的差别待遇，但至少Gitlab社群版有基本的自托管能力，并且是100%开源的。此外，像CodeBerg这种非营利的FOSS软件托管网站，他们的平台是完全自由开源的。
不尊重著作传
Github长期以来便不尊重著作传的价值。历任CEO皆公开对著作传持负面态度。创始人兼前CEO曾在OSCON上的演讲中攻击著作传和GPL。上梁不正下梁歪，多年来我们发现，Github的员工在许多场合都说服人们不要使用著作传条款，甚至还有Github员工在Bug ticket上公开呼吁不要使用著作传条款。
他是微软的财产
Github是微软的全权子公司，微软过去便不断攻击著作传条款。
2. 要怎样弃用Github呢？
专有软件的厂商陷阱导致人们难以离开Github。我们担心的是，Github作为「工程师的Facebook」已经成功制造了有史以来最诱人的围墙花园，吸引了无数FOSS软件开发者。就像离开Facebook，你就会不知道怎样跟朋友家人联络；离开Github，你就会不知道怎样认识其他开发者，以及和其他开发者合作。 Github甚至会成为向你雇主展示开发成果的平台。我们也知道有些计算机科学的课程还会要求学生去使用Github。
因此，我们呼吁现况为舒适安稳的FOSS专案领导者、开发者、管理者、面试官，能够拒绝使用Github的专有软件服务。我们知道你可能会受到未来雇主、雇佣你开发FOSS专案人士的压力，要你使用Github。这类集体行为，需要上层开发者首先做出行动才能改变，以成为他人榜样。这也是为何我们不只要你离开Github，还要协助更多人放弃Github。你可以协助新加入的开发者，避免被Github导致的内部权力不平等所伤害。设定议程，将你的FOSS专案托管在其他平台。
同时，我们也向面试官、社群领导者，还有那些鼓励新加入的贡献者使用Github的上层人士喊话。一旦你决定将专案托管在Github，个人贡献者就不得不使用Github的专有且伤害性的产品。如果你是决策者，或是社群中拥有权力的人士，我们希望你能将社群的贡献导向FOSS的平台，而非Github。如果你是个人开发者，觉得离开Github倍感困难，那请阅读我们下面的推荐方法，之后会再陆续新增。
为了未来考量，我们会让这个网址保持不变，并能从GiveUpGitHub.org连结过来，内含帮助大众的资源，协助上层开发者、新手开发者，以及众多的FOSS软体贡献者离开Github。如果你认为你的专案还无法脱离Github，我们希望你能把这段声明加入到README.md，宣示你的态度。如果你已经离开了Github，请改用这段README.md的模板取代现有的版本。
千里之行始于足下。
The journey of a thousand miles begins with a single step.
— 老子 (Lao Tsu) in Chapter 64 of 道德经 (Tao Te Ching)
3. 弃用Github的帮助资源
这里是帮助你离开Github的资源。如果有更多资讯，我们会随时更新此列表。如果你想跟我们分享尚未列在上面的资源，请在Give-Up-GitHub邮件清单跟我们讨论。
替代托管服务
CodeBerg
SourceHut
自托管(或加入自托管群组)，有以下选项
Gitea
Gitlab社群版 (注意，Gitlab.com上的Gitab企业版就跟Github一样，含有许多商业软件、专有软件，会有专有厂商体陷阱。)
（我们很快就会加入架设自托管服务的教学！）
4. 在弃用Github前，你可以做的事
即使你还是Github用户，你还是可以帮忙唤醒大众关注这个议题。 (未来将加入更多方法)
将这段声明加到你的README.md，跟使用者分享你对Github的看法。
在贡献Github上的专案前，用尊重和友善的口气询问开发者，是否能使用Github以外的方法进行贡献。
向雇主说明依赖Github的专有软件和厂商陷阱的风险。
加入give-up-github的邮件清单，分享你离开Github的难处。这样能帮助我们寻找解决方式，并将解决方法添加至此页面。
github的pull request是指什么意思
pull request就是请求别人pull自己的仓库。
当然，一般发起pull request的人都是从被请求人，那里clone的代码(github上则可以直接fork)，一般比被请求人的项目提前若干commit。
pull request只是一种项目合作形式，github只是整合了相应功能，脱离github照样能pull request。
比如Linux内核项目，直接给linux发邮件，标题就是Pull Request。邮件里写上git的url和新增的feature或者修的bug。
如果linux觉得ok，就会根据给出的git url去git pull，github只是把上述过程集成在了站内，更加方便新人。
扩展资料：
github 合作开发模式主要有三种。
一、Fork 方式。
开发者 fork 自己生成一个独立的分支，跟主分支完全独立，pull代码后，项目维护者可根据代码质量决定是否merge代码。
二、组织。
组织的所有者可以针对不同的代码仓库建立不同访问权限的团队。
新建一个组织，然后添加项目成员，根据提示设置完毕，在仓库的Collaborators 下面的Teams就可以添加或者remove组织成员
三、合作者。
代码仓库的所有者可以为单个仓库增加具备只读或者读写权限的协作者。
合作者方式比较实用，也很方便，新建一个Repository，完毕之后，进入Repository的Settings，然后在Manage Collaborators里就可以管理合作者了。
参考资料来源：百度百科——github
