Git学习笔记

git是什么 有什么用处 以及git的历史就不介绍了 都可以从各种百科上面查到 下面直接写git的基本操作

下载安装

这一步也就跳过了 下载安装没有什么困难的
判断是否安装完成
在命令行中输入git 如果出现下面的提示那就说明安装完成了

git具体命令

第一步

• 新建一个文件夹
  mkdir test(创建文件夹test)
  cd test（进入到该文件夹）
  touch a.md（新建a.md）

• git status
  查看当前目录的状态

  
  
  
  

  意思是现在还不是一个git目录

• 初始化git仓库
  git init

  
  

可以看到初始化成功

• 再次输入git status 查看状态

  
  

大部分的单词都认识 需要注意的是Untracked files 意思是说a.md这个文件还没有被跟踪 还没有提交到仓库中 并且提示可以用git add命令去操作想要提交的文件

• git add
  我们先随意编辑下a.md然后输入 git add a.md
  然后在输入git status 看下当前的状态

  
  
  
  

  此时可以看到Changes to be committed 意识是有文件等待被提交 等待的文件在下面有列出来 即是我们刚刚修改的a.md这个文件
  同样提示我们可以采用git rm --cached 这个命令区移除这个缓存

• git commit
  接着我们输入 git commit -m "first commit"
  commit 是提交的意思 m代表提交的信息 即我们可以后后面添加本次提交的说明 这次的说明就是 first commit
  这是我们在输入 git status 会提示nothing to commit

  
  

• git log
  输入git log可以看到提交的日志
  并且可以看到提交的附加信息为 "first commit"

  
  

• git add 和 git commit
  这两步可以合并为一步 但是不建议这么使用 防止误提交

• git branch
  branch即使分支的意思
  git init之后会有一个默认主分支 master
  git branch 查看当前的分支情况

  
  
  image.png
  
  

  创建分支
  git branch a 就新建了一个名为a的分支
  再次查看分支情况

  
  
  
  分支前面有一个*号 表示当前在这个分支下
  切换分支
  git checkout a
  创建切换分支一步到位
  git checkout -b a

• 合并分支
  git merge
  首先切换到要合并的的目标分支 执行git merge a 意思是将a分支的代码合并过来

• 删除分支
  git branch -d a 把a这个分支给删除

• 强制删除
  有时会删除失败
  git branch -D a 把a这个分支强制删除

• 创建当前代码的版本号
  git tag
  在当前代码状态 git tag v1.0 就代表了在当前代码状态下新建了一个v1.0的标签
  git tag可以查看历史tag记录

以上都是在脱机环境下进行的 下面记录是真实链接到gitub云的情况

• SSH
  首先先介绍ssh的概念 ssh类似于一种授权 ssh是一种网络协议 用于计算机之间的加密登陆

• 生产 SSH key
  正常情况下Linux和Mac是默认安装ssh的，现在的实验环境和书写环境均是Mac，所以一下的所欲步骤均按照Mac来进行。正常情况下Windows的步骤是差不多的，如果有不同的地方会进行说明。
  在终端中输入ssh 如果出现来以下提示说明本机已经安装来ssh 。否则自行搜索安装ssh

  
  
  
  

  windows下是在Git Bash中进行输入的。
  接着输入ssh-keygen -t rsa 指定用rsa算法生产秘钥，连续三个回车，密码不需要输入。系统会自动生成两个文件 id_rsa 和 id_rsa.pub。其中 id_rsa是秘钥，id_rsa.pub是公钥。Linux/Mac 可以在～/.ssh下找到，win下在/c/Documents and Settings/username/.ssh下找到，需要注意的是他们都是隐藏文件。
  在本地生产秘钥和公钥就完成来，接下来就是要把公钥 id_rsa.pub 添加到GitHub 上，本地的秘钥和公钥进行配对，授权成功才可以提交代码。

• 在GitHub 上添加 SSH key

  • 在GitHub设置界面上点击最左侧的SSH and GPR keys
    
    
    然后点击右上角的New SSH key按钮：
    
    
    需要做的就是把id_ras.pub填写到key那栏里面， title死不需要填写的 点击Add SSH key 就可以了
    
    添加完成之后的样子
    
    添加完成之后输入 ssh -T [email protected] 进行测试 如果出现一下提示说明添加成功了
    
    成功提示

• 4 Push & Pull
  在提交代码之前线了解两个命令 push pull 这是上面的文章没有介绍的 因为需要远程仓库的配合
  push：直译过来就是推的意思 本地代码有更新了需要吧代码推到远程仓库，这样本地仓库跟远程仓库就保持同步了
  代码实例：

git push origin master

意思就是把本地代码推到远程master分支
push：
意思直译过来就是拉的意思，如果别人提交代码到远程仓库，这个时候需要把远程仓库的代码拉下来，保证两端的代码同步
代码实例：

git pull origin master

• 5 提交代码
  添加SSH Key 成功后，我们就有权限向GitHub上我们自己的项目提交代码拉，提交代码有两种方法：
  clone自己的项目 一strom zhang在

Github上创建的test为例，执行下面的命令：

git clone [email protected]:stormzhang/test.git

这样就把test项目clone到了本地，可以把clone理解为高级点的复制，这个时候该项目本身就已经是一个git仓库了，不需要执行git init进行初始化，而且甚至都已经关联好了远程仓库，我们只需要在这个test目录下任意修改或者添加文件，然后进行commit ，之后就可以执行：

git push origin master

进行代码提交，这种事最简单方便的一种方式。

• 如何获取项目的仓库地址？如下图：

  
  
• 关联本地已有项目
  如果我们本地已经有一个完整的git仓库，并且已经commit多次，这个时候第一种方法就不适合了
  假设我们本地有个test2的项目，我们需要的是在GitHub上建一个test的项目，然后把本地test2上的所有代码commit记录提交到GitHub的test项目
  第一步就是在GitHub上建一个test项目，这个上面有讲
  第二步把本地test2项目与GitHub上的test项目进行关联，切换到test2目录，执行如下命令：

git remote add origin [email protected]:stormzhang/test.git

什么意思呢？就是添加一个远程仓库，他的地址是[email protected]:stormzhang/test.git，而origin是给这个项目的远程仓库起的名字，是的，名字可以随便取，只不过大家公认的只有一个远程仓库时的名字就是origin，为什么要给远程仓库去名字？因为我们可能一个项目有多个远程仓库。比如。比如GitHub一个，公司一个，这样的话提交到不同的远程仓库就需要指定不同的仓库名字了。
查看我们当前项目有哪些远程仓库可以执行如下命令：

git remote -v

接下来我们本地的仓库就可以向远程仓库进行代码提交了：

git push origin master

就是默认向GitHub上的test目录提交了代码，而这个代码是在master分支。当然也可以提交到指定的分支。后面会有。
在提交代码前要先设置下自己的用户名和邮箱，这鞋信息会出现在所有的commit记录里，执行下面的代码：

git config -global user.name "JackCui"
git config -global user.email "*****"

Git 进阶

• 用户名和邮箱
  我们知道我们进行每一次的commit都会产生一条log，这条log标记了提交人的姓名和邮箱，以便其他人方便查看与联系提交人，所以我们在进行提交的第一步就是设置自己的用户名和邮箱
  执行下面的代码：

git config --global user.name "JackCui"
git config --global user.email "****"

以上进行了全局设置，当然有些时候我们的某一个项目要用到特定的邮箱，这个时候只需要切换到你的项目，以上的代码把--global参数去掉，再重新执行一边就可以了
PS：我们在GitHub的每次提交理论都会在主页下面产生一条绿色的小方块的记录，如果你确认提交了，但是没有绿色方块的显示，那肯定是调教代码设置的邮箱和GitHub上的邮箱不一致，GitHub上的邮箱可以到Setting->Emails 里查看

• alias
  我们知道我们执行的一些Git命令其实操作很频繁的类似有：

git commit
git checkout
git branch
git status

这些操作很频繁，每次都要输入完全是不是有点麻烦，有没有一种简单的缩写输入呢？比如：

git c
git co
git br
git s

这样的话很简单快捷，这似乎时候就要用到alias配置了，翻译过来就是别名的意思，命令：

git config --global alias.co checkout 
git config --global alias.ci commit

以上的别名不是固定的，可以完全根据自己的习惯去制定
另外这里给大家推荐一个很强大的alias命令，我们知道我们输入git log产看日志的时候是这个样子的：

image.png

输入git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s%Cgreen(%cr)%C(bold blue)<%an>%Creset' --abbrev-commit --date=relative 然后日志就这样了：

image.png

是不是比较清晰了，整个分子好的走向也很明确，但是每次都要输入这么一大串是不是很烦，这时也可以使用alias啊：

git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative"

这样以后直接输入git lg就行了

3 其他配置

当然还有一些其他有用的配置，默认情况下git用的编辑器是vi，如果不喜欢可以改成其他编辑器，比如vim。

git config --global core.editor "vim" #设置editor使用vim

也可以使用其他编辑器，前提是本机有安装。
截图中是带有颜色的，默认是没有的。输入下面命令就可以了：

git config --global color.ui true
git config --global core.quotepath false #设置显示中文文件名

以上所有的配置就都差不多了，默认这些配置都在~/.gitconfig文件下，可以找到这个文件查看自己的配置，也可以输入git config -l 命令查看。

4. diff

diff命令是很常用的，使用场景是我们经常在做代码改动，但是有时候是2天前代码了，做了哪些改动都忘记了，在提交之前需要确认，这个时候就可以用diff来查看你到底做了哪些改动

image.png

红色的代表删除的，绿色的代表增加的，这里可以一目了然的看到我到底对这个文件做了哪些改动。
值得一提的是直接输入git diff只能比较当前文件和暂存文件差异，什么事暂存区？就是还没有执行git add的文件。
当然和暂存区做比较之外，还有其他用法，如比较两次commit之间的差异，比较两个分支之间的差异，比较暂存区和版本库之间的差异等。

git diff <$id1><$id2>#比较两次提交的差异
git diff ..#在两个分支之间比较
git diff --staged #比较暂存区和版本库差异

5.checkout

我们知道checkout一般作为切换分支使用，比如切换到develop分支可以使用

git checkout develop

但是checkout不止作为切换分支，他可以用来切换tag，切换到某次commit，如：

git checkout v1.0
git checkout ffd9adfeaefdfaefdgeaeea#后面一串是commit_id，是每次commit的SHA1，可以根据git log看

除了有“切换”的意思，checkout还有一个撤销的作用，举个例子，假设我们在一个分支开发一个小功能，刚写完一半，这个时候需求变了，而且是大变化。之前写的代码完全用不了了，好在刚写，甚至都没有git add进暂存区，这个时候很简单的一个操作就是直接把源文件还原：

git checkout a.md

checkout只能撤销还没有add进暂存区的文件

6.stash

设想一个场景，假设我们正在一个新的分支做新的功能，这个时候突然有一个紧急的bug需要修复，而且修复完之后需要立即发布。当然你说我先把刚写的文件进行提交不就行了吗。这样理论上当然是OK的，但是这会产生垃圾commit，原则上我们每次commit都要有实际的意义，你的代码只是刚写了一半，还没有实际的意义不建议就这样commit的，那么有没有一种比较好的办法，可以暂时切换到别的分支，修复完bug再切回来，而且代码也能保留的呢？
这个时候stash命令就大有作用了，前提是我们的代码没有进行commit，哪怕你执行了add也没有关系，先执行

git stash

命令，什么意思呢，就是把当前分支所有没有commit的代码先暂存起来，这个时候你再执行git status会发现当前的分支很干净，几乎看不到任何改动，你的代码改动也看不见了，但是其实是先暂存了起来，执行

git stash list

会发现暂存区有一条记录。
这个时候可以切换到其他分支，赶紧把bug修改好然后发布，紧接着再切换回来继续之前没有完成的功能，但是之前的代码怎么还原呢？

git stash apply

你会发现你之前所有的代码全部回来了，就好像什么事情都没有发生过一样，最好紧接着把暂存区的这次stash记录删除，执行

git stash drop

就把最近一条stash记录删除了，是不是很方便，其实还有更加方便的，可以使用

git stash pop

来代替apply命令，pop和apply的区别就是pop不但会帮你把代码还原，还自动帮你把这条stash记录删除，省的自己再drop一遍，为了验证可以紧接着执行git stash list命令来确认是不是已经没有记录了
最后还有一个命令：

git stash clear

就是清空所有缓存区的记录，drop只是删除一条，当然后面可以跟stash_id参数来删除置顶的某条记录，不跟参数就是删除最近的，而clear是清空。

7.merge&rebase

我们知道merge是分支合并的意思，我们在featureA分支开发完了一个功能，这个时候需要合并到住分支master上去，我们只需要执行：

git checkout master
git merge feature

其实rebase命令也是合并的意思，上面我们的需求可以

git checkout master
git rebase feature

rebase跟merge的区别子啊雨可以理解成有两个数据，需要把两个书架的书整理到一起，第一种做法就是merge，比较粗鲁暴力，就是直接腾出一块地方把另一个书架的书全部放进区，虽然暴力，但是这种做法你可以知道那些书是来自另一个书架的；第二种做法是rebase，他会把两个的书先进行比较，按照购书的时间进行重新排序，然后重新放置好，这样做的好处就是合并之后的书架看起来更加有逻辑，但是很难清晰的知道那些书来自哪个书架。
各有各的好处，根据自己的需求和不同的习惯进行选择就好

8.解决冲突

假设这样一个场景，A和B个字开了两个分支来开发不同的功能，大部分情况下都会尽量互不干扰，但是有一个需求A需要改动一个基础库中的方法，不巧B这个时候由于业务需要也改动了基础库的这个方法，因为这种情况比较特殊，A和B都认为不会对对方造成影响，等到两人把各自功能做完，需要合并到主分支master的时候，我们假设先合并A的分支，这个时候没有任何问题，之后在合并B的分支，这个时候想想也会有冲突了，因为A和B同时改动了一个地方，Git本身无法判断谁对谁错，但是这个时候他会智能的提示有conficts，需要手动的解决这个冲突再重新进行commit提交，下面举个。

image.png

以上截图就是冲突的事例，冲突的地方由====分出了上下两个部分，上部分一个叫做HEAD的字样代表是我当前所在分支的代码，下半部分是一个角baidu_activity分支的带啊吗，可以看到HEAD对gradle插件进行了升级，同时新增了一个插件，所以我们很容易判断哪些代码该保留，哪些代码该删除，我们只需呀移除那些老旧代码，而且同时也要把那些<<>>>>baidu_acivity这些标记符号也一并删除，最后仅一次commit就ok了。
在开发中一般会约定进行大家写的代码不要彼此影响，以减少冲突的可能，但是冲突总归是无法避免的，需要掌握解决冲突的方法。

团队合作利器：Git分支管理

Git相比于SVN最强大的地方就在于分支，Git的分支操作简直不要太方便，而实际项目开发中团队最依赖的莫过于分支了，关于前面也说了，但是现在会更加详细的讲述什么是分支、分支的具体操作以及实际项目开发中到底是怎么依赖分支来进行团队合作的。

• 1.什么事分支
  可以这么理解：几个人一起去旅游，中间走到一个三岔口，每条路可能有不同的风景，你们约定3天后在某地汇合，然后各自出发了。而这三条分叉路就可以理解成你们各自的分支，而等你们汇聚的时候就相当于把你们的分支进行了合并。
• 2.分支的常用操作
  通常我们默认都会有一个主分支叫master，下面我们先来看关于分支的一些基本操作：
  • 新建一个叫做develop的分支

git branch develop

这里稍微提醒下大家，新建分支的命令是基于当前所在分支的基础上进行的，即以上是基于master分支新建来一个叫做develop的分支，此时develop分支跟master分支的内容完全一样。如果你有A、B、
C、三个分支，三个分支是三位同学的，各分支内容不一样，如果你当前所在B分支，执行新建分支命令，则新建的分支内容跟B分支一样，同理C也是一样。

• 切换到develop分支

git checkout develop

• 如果把以上两部合并，即新建并且自动切换到develop分支：

git checkout -b develop

• 把develop分支推到远程仓库

git push origin develop

• 如果你远程的分支想取名叫develop2，执行：

git push origin develop:develop2

但是强烈不建议这么做，这会导致很混乱，很难管理，所以建议本地分支跟远程分支要保持一致。

• 查看本地分支

git branch

• 查看远程分支列表

git branch -r

• 删除本地分支

git branch -d develop
git branch -D develop(强制删除)

• 删除远程分支

git push origin:develop

• 如果远程分支又个develop，而本地没有，你想所有的develop分支迁移到本地：

git checkout develop origin/develop

• 同样的把远程分支迁移到本地顺便切换到该分支：

git checkout -b develop origin/develop

• 基本的团队协作流程
  一般来说如果你是一个人开发，可能只需要master、develop两个分支就够了，但是平时开发在develop分支进行，开发完成之后，发布之前合并到master分支，这个流程没啥大问题。
  但是是3、5个人那就不一样了，有人说也没有大问题啊，可以新建A、B、、C三个分支，每个人各自开发自己的分支，然后开发完成后逐步合并到master分支。然而现实却是，你正在某哥分支开发某个功能，这个时候突然发现线上一个很严重的bug，不得不停下手头的工作先处理bug，而且很多时候多人协作下如果没有一个规范，很容易产生问题，所以多人协作下的分支管理规范很重要，就跟代码规范一样重要，下面说下一种分支管理流程Git Flow。

4.Git Flow

准确的说Git Flow是一种比较成熟的分支管理流程，工作流程图：

有点懵逼。
一般来说，大部分情况下都会有两个分支master和develop，他们的职责分别是：

• master：永远处在即将发布（production-ready）状态
• develop：最近的开发状态
  确切的说master、develop分支大部分情况下都会保持一致，只有在上线前测试阶段develop比master的代码要多，一旦测试没问题，准备发布了，这时候会将develop合并到master上。
  但是我们发布之后又会进行下一版本的功能开发，开发中间可能又会遇到需要紧急修复bug，一个功能开发完成之后突然需求变动了情况，所以Git Flow除了以上master和develop两个主要分支除外，还提出了以下三个辅助分支。
• fuature：开发新功能的分支，基于develop，完成后merge回develop
• release：准备要发布版本的分支，用来修复bug，基于develop，完成后merge回develop和master
• hotfix：修复master上的问题，等不及release版本就必须马上上线。基于master，完成后merge回master和develop
  什么意思你？
  举个例子，假设我们已经有master和develop两个分支了，这个时候我们准备做一个功能A，第一步我们要做的，就是基于develop分支新建分支：

git branch feature/A

看到了吧，其实就是一个规范，规定了所有开发的功能分支都以feature为前缀
但是这个时候做着做着发现线上有一个紧急的bug需要修复，那紧急停下手头的工作，立即切换到master分支，然后再在此基础上新建一个分支：

git branch hot fix/B

代表新建了一个紧急修复分支，修复完成之后直接合并到develop和master，然后发布。
然后再切回我们的feature/A分支继续着我们的开发，如果开发完了，那么合并回develop分支，然后再develop分支属于测试环境，跟后端对接并且测试的差不多了，感觉可以发布到正式环境了，这个时候再新建一个release分支：

git branch release/1.0

这个时候所有的api、数据等都是正式环境，然后在这个分支上进行最后的测试，发现bug直接进行修改，知道测试ok达到发布的标准，最后把该分支到develop和master然后进行发布。
以上就是Git Flow的概念与大概流程，看起来很复杂，但是对于人数比较多的团队协作现实开发中确实回遇到这么复杂的情况，是目前和流行的一套分支管理流程，但是会有人问每次都要各种操作，合并来合并去，有点麻烦，这点Git Flow早就想到了，为此还专门推出了一个Git Flow工具，并且是开源的。
GitHub地址：https://github.com/nvie/gitflow
简单点来说：就是这个工具帮我们省下了很多步骤，比如我们当前处于master分支，如果想要开发一个新的功能，第一步切换develop分支，第二部新建一个以feature开头的分支，有了Git Flow 直接入下操作就可以了：

git flow feature start A

这个分支完成之后，需要合并到develop分支，直接执行下面的操作就可以了：

git flow feature finish A

如果是hotfix或者release分支甚至自动帮你合并到develop、master两个分支。

GitHub常见的几种操作

我们都说开源社区最大的魅力是人人都可以参与进去，发挥众人的力量，让一个项目更完善，更强壮。那么肯定有人疑问，我自己目前还没有能力开源一个项目，但是想一起参与到别的开源项目中，该怎么操作呢？
姑且那Square公司开源的Retrofit为例来介绍
打开链接：
https://github.com/square/retrofit
然后看到如下的项目主页：

image.png

可以看到一个项目可以进行的操作主要就是两部分，第一部分包括Watch、Star、Fork，这三个操作之前的系列介绍过来。
我们着重来看第二部分，分别包括Code、Issues、Pull requests、Projects、Wiki、Pulse、Graphs。接下来我们来一个个解释下。

• Code
  这个好理解，就是你项目的代码文件而已，这里说明一下，每个项目通常都会有对该项目的介绍，只需要在项目的根目录里添加一个README.md文件就可以，使用markdown语法，GitHub自动会对该文件进行渲染。

• Issues
  Issues代表项目的一些问题或者bug，并不是说Issues越少越好，Issues被解决的越多说明项目作者或者项目响应很积极，也说明该开源项目的做着很重视该项目。我们来看下Retrofit的Issues主页，截止目前close（解决）了以前多个Issue，open（待解决）状态的有37个，这还是很值得我们学习的。

  
  
  
  

  同样的，大家在使用一些开源项目有问题的时候都可以提Issues，可以通过点击右上角的New Issues来新建Issue，需要添加一个标题和描述就可以了，这个操作很简单。

• Pull requests
  我们都知道GitHub的最大魅力在于人人都可以参与，比如别人开源一个项目，我们每个人都可以一起参与开发，一起来完善，而这都通过Pull requests来完成，简称PR。这个没法在Retrofit演示，下面在自己的GitHub上的项目9GAG来演示下怎么给一个项目发起PR：
  说明下，必须确保可以正常向GitHub提交代码，如果不可以的话，自己找下问题。
  第一步登陆自己的GitHub账号，找到想要发起PR的项目，这里以9GAG为例，点击右上角的Fork按钮，然后该项目就出现在了自己的账号的Repository里。
  需要注意，这个项目原本是属于GitHub账号stormzhang下的，为了说明，又重新注册了一个账号。
  Fork之后，在新的账号下多了一个9GAG的项目，截图显示如下：

  
  
  image.png
  
  

  可以看到Fork过来的项目标题底部会显示一行小字：fork from stormzhang/9GAG,除此之外，项目代码根原项目一模一样，对于原项目来说，对于原项目来说，相当于别人新建了一个分支而已。
  第二步：把该项目clone到本地，然后修改的bug也好，想要增加的功能也好，总之把自己做的代码改动开发完，保存好，为了方便演示，这里只是把原项目的README.md文件添加了一行：Fork from stormzhang!
  接着，把自己做的代码改动push到自己的GitHub上去。
  第三步：点击你的Fork过来的项目主页的Pull requests页面，

  
  
  image.png
  
  点击New pull request按钮紧接着到如下页面：
  
  image.png
  
  这个页面自动会比较该项目与原项目的不同之处，最顶部声明了是stormzhang/9GAG项目的master分支与你fork过来的gooddev/9GAG项目master分支所做的比较。
  然后最顶部可以方便看到到底代码中做了哪些改动，你们也看到我时及时加了一句Fork from stormzhang!
  同样的我也好标题和描述，然后我们点击中间的Create pull request按钮，至此我们就成功给项目提交了一个PR。
  然后就等着项目原作者review你的代码，并且决定会不会接受你的PR，如果接受，那么恭喜你，你已经是该项目的贡献者之一了。
• Projects
  这个是最新的GitHub改版新增的一个项目，这个项目就是方便你把一个Issues、Pull requests进行分类，比较鸡肋，了解下就好

• Wile
  一般来说，我们项目的主页有README.md基本就够了，但是有些时候我们项目的一些用法很复杂，需要有详细的使用说明文档给开源项目的使用着，这个时候就用到了Wiki。

  
  
  image.png
  
  

  使用起来也简单，直接New Page，然后使用markdown语法进行编写。

• Pulse
  Pulse 可以理解成项目的活跃汇总。包括近期该仓库创建了多少个Pull Request或Issue，有多少人参与了这个参数的开发等，都可以在这里一目了然。
  根据这个页面，用户可以判断该项目受关注程度以及项目作者是否还在积极参与解决这些问题等。

  
  
  image.png

• Graphs
  Graphs是以图表的形式来展示该项目的一个整体情况，比如项目的全部负责任，比如commits的维度分析，比如某天代码提交的频繁程度等。

  
  
  image.png

  • Settings
    如果一个项目是自己的，那么你会发现会多一个彩蛋Settings，这里包括了你对整个项目的设置信息，比如对项目的重命名，比如删除该项目，比如关闭项目的Wiki和Issues功能等，不过大部分情况下我们不需要对这些设置做更改可以自己了解下。

    
    
    image.png
    
    

    以上就包括了一个GitHub项目的所有操作。

发现好用的开源项目

如何让GitHub帮助我们工作，提升工作效率？
GitHub其中有一个最重要的作用就是发现全世界最优秀的开源项目。

关注一些活跃的大牛

GitHub主页有一个类似微博的时间线功能，所有你关注的人的动作， 比如star、fork了某个项目都会出现你的时间线上，这种方式适合比较懒的人，不用主动去找项目。怎么关注这些人？

Trending

点击下图的Explore菜单到“发现”页面

image.png

Trending直译过来就是趋势的意思，就是说这个页面你可以看到最近一些热门的开源项目，这个页面是主动获取一些开源项目最好的途径，可以选择“当天最热”、“一周最热”、“一月内最热”来查看，并且还可以分语言来查看。

image.png

推荐大家每隔几天就去看下，主动去发掘一些优秀的开源项目。

Search

除了Trending，还有一种最主动的获取开源项目的方式，那就是GitHub的Search功能，举个例子，你是做安卓的，刚刚接触GitHub没多久，第一件事情就应该输入android关键字进行搜索，然后右上角按照star来排序，结果如下图：

image.png

同理IOS也是一样：

image.png

可以按照star数，排名靠前基本是一些比较火的项目，一定是很有用的才会这么火，值得一提的是左侧依然可以选择语言进行过滤
对于实际项目中用到的一些库，基本上都会第一时间去GitHub搜索有没有类似的库，比如项目中想要采用一个网络库，那么不妨输入android http关键字进行搜索，按照star数进行排序

image.png

可以看到最流行的网络库。
GitHub的Search还有一个小技巧，比如说想搜索结果中star大于1000的，那么可以这么搜索：
android http stars：>1000
某些人如果习惯用Google进行搜索，那么想搜索GitHub上的结果，不妨前面加GitHub关键字就OK了，比如我在google里面输入GitHub Android http，每隔关键字用空格隔开，然后搜索结果如下：

image.png

尾声

• https://github.com/EbookFoundation/free-programming-books
  这个项目整理和编程有关的免费书籍，全球多国语言版本都有，中文版的：https://github.com/EbookFoundation/free-programming-books/blob/master/free-programming-books-zh.md
• https://github.com/robbyrussell/oh-my-zsh 目前最流行的shell oh-my-zsh
• https://github.com/sindresorhus/awesome 搜罗整理了GitHub上个领域的资源大汇总
• https://github.com/tiimgreen/github-cheat-sheet/
  GitHub的各种使用技巧