git --分布式版本控制软件，免费而超好用的git

gitHub是使用git进行版本控制的代码管理网站

Linux系统不断发展，已经成为最大的服务器系统软件了。

CVS和SVN都是集中式的版本控制系统，而Git是分布式版本控制系统。

区别：集中式版本控制系统是，干活的时候用的都是自己的电脑所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。

中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆

集中式版本控制系统最大的毛病就是必须联网才能工作。

分布式版本控制系统根本没有‘中央服务器’，每个人的电脑上都是一个完整的版本库，这样就可以不用联网了，

但是如果你在自己电脑上修改了文件A，你的同事也修改了A，你们两个需要互相推送就可以看到对方的修改了。

分布式版本控制系统通常也有一台充当‘中央服务器’的电脑，这个服务器用来‘交换大家的修改’，交换修改更方便。

Git极其强大的分支管理

总体思路图解：

Git命令常用快捷式

使用git,首先需要下载git并进行安装，官方网址为：https://git-scm.com/进行下载git

安装完成后，还需要最后一步设置，

配置本地用户信息

 $ git config --global user.name "Your Name" //配置用户名，Your Name为起的名字

$ git config --global user.email "email@example.com" //配置邮箱

$ git config user.name查看配置的用户名

$ git config user.email查看配置的邮箱

创建版本库：

版本库又名仓库，英文名repository，可以理解成一个目录，这个目录里所有文件都可以被Git管理，每个文件的修改、删除，Git都能跟踪和修改。

    $ mkdir learngit创建文件夹

    $ cd learngit进入目录

    $ pwd            显示当前目录

pwd命令用于显示当前目录，也就是该仓库位于/Users/michael/learngit

第二步，通过git init命令把这个目录变成Git可以管理的仓库

    $ git init

瞬间Git就把仓库建好了，而且也是一个空的仓库，learngit文件下多了一个

.git目录。这个目录是Git来跟踪管理版本库的，不要手动修改

把文件添加到版本库

版本控制系统是没法跟踪word文件的改动，如果要真正使用版本控制系统，就要以纯文本方式编写文件

最好不要使用windows自带的记事本编辑任何文本文件，会遇到很多不可思议的问题。建议使用Nodepad++去代替记事本。

言归正传

编写一个readme.txt文件 一定要放在learngit目录下，因为这是一个Git仓库

第一步

用命令git add readme.txt告诉Git，把文件添加到仓库里面。没有任何消息，说明添加成功。

第二部

用命令git commit告诉Git，把文件提交到仓库：

    git commit -m "wrote a readme file"解释：git commit命令，-m后面输入是本次提交说明，可以输入任意内容，当然通俗易懂

会出现下面内容

    [master (root-commit) 9dfd485] wrote a readme file

    1 filechanged, 2 insertions(+)

createmode 100644 readme.txt解释：1个文件被改动，插入两行内容

//因为commit可以一次提交很多文件，所以你可以多次add不同的文件

比如：

    $ git add file1.txt

    $ git add file2.txt file3.txt

    $ git commit -m "add 3 files."                         

第三步

手动修改readme.txt文件

用命令git status命令查看结果：git status命令让我们时刻掌握仓库当前的状态，readme.txt被修改了，但还没有准备提交的修改

用命令git diff readme.txt命令查看不同，(git add命令之前的查看)可以知道具体修改了哪些内容

知道修改了具体内容我们可以提交修改文件了

第四步

    git add readme.txt同样没有任何提示，添加了文件

    git status我们可以运行这段命令查看仓库状态

    git commit -m "add distributed"提交的修改文件readme.txt

    git status提交后再次用这段命令查看仓库的当前状态，得到当前没有需要提交的修改，工作目录是干净的

总结：git status命令可以随时掌握工作区的状态，如果告诉你有文件被修改过，那么就用git diff查看修改内容

版本回退

这里我们可以再次对readme.txt进行修改，然后再次提交。

    git log这段命令我们就可以知道我们什么时候修改了什么内容，可以得到提交的修改

现在我们准备回到readme.txt回退到上一个版本，也就是"add distributed"这个版本

git中，HEAD表示当前版本。上一个版本 HEAD^, 上上一个版本 HEAD^^,上100个版本写成HEAD~100

现在我们将当前版本回退到上一个版本"adddistributed"

    git reset --hard HEAD^便可以得到当前版本的上一个版本

    cat readme.txt这段命令可以知道readme.txt中的详细内容

果然退回到上一个版本

    git log再次查看当前版本库的状态，刚才的版本不见了，21世纪回到了19世纪，想再回去21世纪如何？

只要命令行没有关掉我们就可以往上面找，找到刚才版本的commitid是多少

    git reset --hard 82aa873c95a1(只需要写前几位，没必要写全，Git会自动去找)

    cat readme.txt再次查看，发现刚才的版本已经回来了

比如说现在你回退到某一个版本，关掉电脑。第二天后悔想恢复到新版本该咋办？找不到新版本的commit id？

想要回退到最新的版本，就必须找到最新版本的commit id

    git reflog这段命令用来记录你的每一次命令便可以得到commit id

总结：

HEAD指向的版本就是当前版本，因此Git允许我们在版本历史间穿梭 Git reset --hard commit_id

git log可以查看提交历史，以便确定要回退到哪个版本

要重返未来版本 用git reflog查看命令历史，以便确定要回到未来的哪个版本

工作区和暂存区

工作区：

就是电脑里面可以看到的目录，比如我的learngit文件夹就是一个工作区。

版本库：

工作区有一个隐藏的目录.git   是Git的版本库

Git版本库存了很多东西，最重要的是stage（index）的暂存区

还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD

前面我们把文件往Git版本库添加时候，是分两步执行的：

第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区

第二部是用git  commit提交修改，实际上就是把暂存区的所有内容提交到当前分支

我们对readme.txt做出修改，

然后在工作区新增加一个license文本文件

git status查看一下状态：readme.txt被修改了，而license没有被添加过，状态是Untracked

使用两次git add命令，将readme.txt和license都添加，

git status再次查看状态

所以git add命令实际上把要提交的所有修改放到暂存区（Stage）

然后执行git  commit就可以一次性把暂存区的所有修改提交到分支

使用命令

git  commit –m “understand how stage works”执行提交

管理修改

Git比其他版本控制系统设计的优秀在于Git跟踪并管理的是修改而不是文件

简单测试：第一次修改文本- git add第二次修改文本 –> git commit

Git管理的是修改，当我们使用git add命令后，在工作区的第一次修改被放入暂存区，准备提交。

但是在工作区的第二次修改并没有放入暂存区，所以git  commit只负责把暂存区的修改提交了也就是第一次的修改被提交了，第二次的修改不会被提交。

当然如果你想两次修改都提交到工作区，可以

第一次修改文本-git add第二次修改文本 –> git add 

在通过命令git commit

撤销修改

你一不小心在你的最后一行添加your boss is stupid

使用命令 git checkout -- readme.txt解释：把readme.txt文件在工作区的修改全部撤销。

1、readme.txt 从修改后还没有被放到暂存区，现在撤销修改就回到和版本库一模一样的状态

2、readme.txt已经添加到暂存区，又作修改，撤销修改就回到添加暂存区后的状态                   

重点：你写了上面的my stupid boss still prefers VSN.而且使用命令 git add 到暂存区了

但是修改只是添加到了暂存区，还没有git commit提交

Git同样告诉我们，用命令git reset HEAD file可以把暂存区的修改撤销掉，重新放回工作区

使用命令git  reset  HEAD  readme.txt可以把暂存区的修改撤销掉，重新放回工作区

在工作区中将my stupid boss still prefers VSN这个修改丢弃

使用命令git  checkout --  readme.txt将工作区最后的修改丢弃。

总结：

场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file。

场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD file，就回到了场景1，第二步按场景1操作。

场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。

删除文件

在Git中，删除也是一个修改操作。

一确实要从版本库中删除该文件

git rm test.txt删除文件

git commit –m ‘remove test.txt’提交  文件从版本库中被删除了

二种是删错了

因为版本库里还有，所以可以很轻松把误删除的文件恢复到最新版本

    git checkout -- test.txt

git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除都可以一键还原

-------------------------------------------------git  end ------------------------------------------

远程仓库

介绍Git的杀手级功能

Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上，没有主次之分。

实际情况往往是，一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个’服务器’仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。

GitHub神奇的网站，提供Git仓库托管服务的。

本地的Git仓库和GitHub仓库之间的传输是通过SSH加密的。

第一步：创建SSH Key看看有没有.ssh目录，如果有，确定有没有id_rsa 和id_rsa.pub这两个文件，如果有请直接跳至下一步，没有请使用命令

    ssh-keygen -t rsa -C ‘759945821@qq.com’ 

id_rsa是秘钥，不能泄露出去

id_rsa.pub是公钥 可以放心地告诉任何人

第二步登录GitHub，打开个人主页，SSH Keys页面

然后点击”Add SSH Key”,填写任意的Title,在Key文本框粘贴id_rsa.pub文件的内容

点击Add Key.

为什么GitHub需要SSH key？

因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议。所以GitHub只要知道你的公钥，就可以确认你自己才能推送。

当然GitHub允许你添加多个Key，可以在公司也可以在家，只要把每台电脑的key都添加到GitHub，就可以在每台电脑上推送了。

GitHub上免费托管的Git仓库，任何人都可以看到，但只有你才可以修改。

可以交钱变成私有的，也可以自己动手搭一个Git服务器，因为你自己的服务器，别人看不见。这样我们就可以开始学习远程库了。

添加远程库

已经在本地创建了一个Git仓库后，又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步，这样GitHub上的仓库既可以备份，也可以让其他人通过该仓库来习作，一举多得。

在GitHub中找到Create a new repository

输入Repositoryname，在这里我们是learngit,其他保持不变

就成功地创建了一个新的Git仓库

在本地git输入命令

    git remote add origin git@github.com:xxxx/learngit.git 

添加后，远程库的名字就是origin这是Git的默认叫法origin 是就是远程库。

接下来一部就是，可以把本地库的所有内容推送到远程库上

git push –u origin master 

把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。

由于远程库是空的，我们第一次推送master分支时，加上-u参数，Git不但会把本地的master分支推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令了。

从现在起，只要本地作了提交，就可以通过命令

git push origin master现在也就是正式拥有了分布式版本库

总结：

要关联一个远程库，使用命令git remote add origin git@github.com:mangoyi/learngit.git

关联后使用命令

git push –u origin master第一次推送master分支的所有内容

之后本地提交后，就可以使用命令git push origin master推送最新修改

克隆远程库

我们可以先创建远程库，从远程库克隆

我们勾选Initialize thisrepository width a README

这样GitHub会自动为我们创建一个REANME.md文件，创建完毕后可以看到README.md

下一步克隆一个本地库

补充：  命令ssh  git@github.com可以来判断是否配置好权限了

克隆命令 git clone git@github.com:xxx/gitkills.git 

命令  cd gitkills

命令   ls                    得出README.md  已经在我们目录中了

说明克隆成功

GitHub给出的地址不止一个，还可以使用http：//github.com/xxx/gitkills.git

这样的地址，实际上，Git支持多种协议，默认是git：//使用ssh，但也可以使用https等其他协议。https速度慢，还有个最大的麻烦每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https

创建并合并一个分支

具体参考：https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/001375840038939c291467cc7c747b1810aab2fb8863508000

1、 创建dev分支

git checkout –b dev得到：Switched to a new branch ‘dev’

git checkout命令加上-b参数表示创建并切换相当于两条命令

              git branch dev

              git checkout dev

2、git branch命令查看当前分支

git branch得到 *dev

                             master

3、这个时候已经在分支上面，我们在文件夹创建readme.txt文件，此时文件是在dev分支上面的，

4、然后提交

git add readme.txt

git commit –m “branch test”

5、dev分支工作完成，我们就可以切换回master分支

git checkout master得到 Switched to branch ‘master’

6、切换到master时候我们发现readme.txt文件不见了，因为那个提交在dev分支上，而master分支此刻的提交点并没有改变。

7、现在讲dev分支上的工作成果合并到master分支上

git merge dev命令用于合并指定分支到当前分支，合并后便可以查看到和dev分支               提交完全一样，

8、合并完成后我们就可以放心地删除了dev分支了

Git branch –d dev得到：Deleted branch dev(was fec145e)

9、删除后查看branch就只是剩下master分支了

git branch得到* master  只剩下master分支

10、创建合并删除非常快，所以git鼓励你使用分支完成某个任务。合并后在删掉分支 ，这样和直接在master分支上工作效果是一样的，但是过程更安全。

查看分支：git branch

创建分支：git branch dev(名称)

切换分支：git checkout dev(切换到dev分支)

创建+切换分支： git  checkout –b dev(分支名称)

合并某分支到当前分支：git merge dev(分支名称)

删除分支：git branch –d dev (分支名称)

-------2019\

解决冲突：我们在合并分支的时候会出现，比如两个用户修改了同一个文件区域，git会报告内容冲突所以此时我们必须对内容进行修改。

在今天的学习中，

1、使用命令 cd learngit     到达指定的learngit库

2、准备新的分支 feature1分支  git checkout –b feature1  

3、修改readme.txt最后一行，修改为Creatinga new branch is quick AND simple

补充：一：我们可以使用命令 vi readme.txt    便可以直接在命令行修改了

修改完之后按ESC键，退出编辑模式，切换到命令模式

输入：wq 保存修改并且退出vi 编辑文档模式

如果只想保存文件，则只需要输入：w   回后底行会提示写入操作结果，并保持停留在命令模式

二：当然我们也可以找到文件直接打开修改在保存也是可以的。

4、git add readme.txt    

   git commit –m ‘& simple’

现在master分支和feature1分支各自都分别有新的提交

5、git在这种情况是无法执行快速合并， 我们用gitmerge feature1 会告诉我们冲突了，

必须手动解决，然后在提交

6、使用命令git status 也可以看出我们冲突的文件

7、我们查看readme.txt的内容，

这里可以直接用命令vi readme.txt 来编辑我们的内容，然后在保存并且回到命令行

8、在git add readme.txt

git commit –m ‘conflict fixed’这样我们便修改冲突并且提交成功

9、用命令

git  log –graph  –pretty=online  –abbrev-commit这里我们可以查看分支合并的情况

10、    最后删除分支

git branch –d feature1工作完成

分支管理策略

通常合并分支时，git 会采用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

我们用–no-ff方式的git merge

1、任然创建并且切换dev分支

    git checkout –b dev

2、修改readme.txt文件，并且提交一个commit  

    git add readme.txt

    git commit –m ‘add merge’

3、现在我们切换回master

    Git checkout master

4、准备合并dev分支，注意使用—no-ff参数，表示禁用Fast forward模式来合并

git merge  –no-ff –m  ‘merge with no-ff’ dev

解释：因为本次合并要创建一个新的commit,所以加上-m参数，把commit描述写进去

5、合并后我们可以通过命令 git log  看看分支历史

总结：分支策略

后来话：在实际开发中，首先master分支时非常稳定的，也就是仅仅用来发布新版本，平时不能在上面干活。

干活都是在dev分支上面，也可以说dev分支不稳点。

团队合作每个人都有自己的dev分支，dev分支上面合并就可以了

Git分支十分强大，合并分支时，加上—no-ff 参数就可以用普通模式合并，合并后的历史记录里面有分支的信息，而fast forward 合并就卡不出来曾经做过合并。

Bug分支

在软件开发中，bug就像家常便饭，git分支如此强大，所以每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

实战演练，当你接到一个101代号的bug任务时，很自然你会想到创建一个issue-101来修复它，但是当前dev分支的工作还没有提交。

实际情况是工作只进行到一半，还没法提交，预计一天才能提交，但是bug要在2个小时内完成。肿么办？

幸好：Git提供一个stash功能，可以把当前工作现场‘存储’起来，等之后恢复现场继续工作。

1、现在我们在dev分支上，我们对文件readme.txt做出了一些修改但是我们还要继续修改，但是bug在两个小时必须解决，

用命令git stash临时保存工作现场

得到Savedworking directory and index state WIP on dev: 3826324 add merge

HEAD is now at 3826324 add merge

2、可以使用git status查看当前的工作区状态，                                                         

首先确定在哪个分支上修复bug，假定是在master分支上修复，就从master分支创建临时分支

git checkout master切换到master分支

3、创建issue-101分支

git checkout –b issue-101来创建issue-101分支

4、现在修复bug，比如说将Git is free software 修改为 Git is a free software

然后提交git add readme.txt

         git commit - m ‘fix bug 101’

5、修复完成后，切换到master分支，并完成合并最后删除issue-101分支

git checkout master              

git merge –no-ff –m ‘merged bug fix 101’issue-101解释：--no-ff参数合并保存历史记录

   git branch –d  issue-101    

6、101bug修复完成，现在我们要回到dev分支继续干活了

    git checkout dev  

git status解释：查看dev当前的工作区

6、这里是查看工作现场在哪里

git stash list   

得到stash@{0}: WIP on dev: 3826324 add merge     

7、恢复工作现场

一：git stash apply 恢复，但是恢复后stash内容并不删除，需要用git stash drop 来删除。

二：另外一种用 git stash pop恢复,恢复的同时把stash内容也删除

用命令git stash list查看，这样我们就看不到stash内容了

总结：

修复bug时，我们会通过创建的bug分支进行修复，然后合并，再删除

当手头工作还没完成的时候，先把工作现场git bash保存

然后修复bug之后，在git stash pop，回到工作现场。并且删除了stash内容

Feature分支

软件开发中，总有无穷无尽的新功能添加进来，添加一个新功能你肯定不希望把主分支搞乱，所以没添加一个新功能，最好新建一个feature分支，在分支上开发，完成后，合并最后删除该feature分支

实战：接到一个新任务，开发代号为Vulcan的新功能

1、准备开发创建分支

git checkout –b feature-vulcan

2、在文件中添加vulcan.py 文件，

3、git add Vulcan.py    //添加文件到暂存区  

git status            //查看当前状态

git commit –m ‘add feature vulcan’  //提交文件到版本库

4、切回dev分支或者master分支，准备合并

git checkout master切回master分支

5、但是此时上级命令经费不足，取消新功能。

git branch –d feature-vulcan     //想删除该分支

结果：error: The branch 'feature-vulcan' is not fully merged.

If you are sure youwant to delete it, run 'git branch -D feature-vulcan

6、Gif提醒feature-vulcan分支还没有被合并，如果删除就会丢掉修改，如果想强行删除

git branch –D  feature-vulcan强行删除分支   完成任务

多人协作

---当你从远成仓库克隆的时候，实际上Git把本地的master分支和远程的master分支对应起来，并且远成仓库的默认名称是origin

查看远程库的信息用git remote

即git remote结果： origin

或者更加详细的是git remote –v结果更加的详细

推行分支：

推送分支就是把该分支上的所有本地提交推送到远程库，推送时候，要指定本地分支。Git就会把该分支推送到远程库对应的远程分支上。

git push origin master  

当然要推送其他分支比如dev就改成 git push origin dev

但是并不是一定要把本地分支往远程推送，哪些分支需要推送呢

master分支时主分支要时刻与远程同步

dev分支时开发分支，团队所有成员都需要在上面工作，也需要远程同步

bug分支只用于本地修复bug，就没必要推到远程了

feature分支是否推送到远程，取决于你是否和你的小伙伴合作在上面开发

抓取分支：

多人协作时，大家都会往master和dev分支上推送各自的修改。

补充：比如我们在learngit库中有一个文件test.txt

我们需要git add test.txt

              git commit test.txt –m  ‘commit test.txt’

最后我们使用命令 git push origin master

这时就会将我们修改的test.txt文件上传到远程库中，就是放在网上了

注意一定先add然后commit最后在git push…  少一步都不可以。

一个电脑要如何去尝试多人合作的实战，首先先创建另外一个文件目录test

1、cd test 进入到test文件那文档操作

2、就会发现出现了这个    ~/test，说明已经进入test文件中

3、然后我们用命令git clone git@github.com:mangoyi/learngit.git

这样我们就可以clone一份learngit库到我们的test文件中，

4、cd learngit 用这个命令进入到master分支

这样便可以操作了也就是说在我们test文件里面的learngit也和远程库连接在了一起，我们就可以通过修改test.txt然后push到远程库中，但是注意我们现在的操作是在test 文件夹里面的leargit文件中，和test同一级目录里面还有一个我们learngit文件。

在这里我们要知道我们现在是在master分支，而我们模拟的是想在dev分支上开发，所以就必须远程创建origin的dev分支到本地，

一、于是我们用命令

git checkout –b dev origin/dev会报错

解决方法：http://blog.csdn.net/weichuang_1/article/details/48437911

//我们来创建一个新的本地分支dev

git checkout –b dev     

//重置它的起始点

git reset –hard origin/dev        

// origin/dev意味着origin索引的远程仓库有dev分支

/*也就是理解成如果原创仓库中没有origin/dev这个分支的话，

你只需要创建一个本地分支dev，然后将它推送到远程仓库

*/

git push –u origin dev

//这样本地的分支dev和原创跟中的分支origin/dev之间建立一个联系

到这里一的问题已经解决了。

二、现在我们在dev分支上创建一个文件hello.py

在hello.py上添加内容

    print('helloworld')

我们将dev分支上

通过命令git add hello.py

         git commit –m ‘addtest/learngit/hello.py’

git push origindev    //推送到远程库分支

（相当于一个小伙伴）另外一个目录下的分支已经推送了他的提交。

推送完在我的github上面可以看到dev分支的推送内容

补充一下：此时你在的路径是

你需要返回上一级命令cd .. (cd和后面的.. 之间有一个空格)

一直退到这里，在cd learngit到达我们自己的仓库master分支

这个时候已经不是在模拟你的小伙伴了而是你自己，

你用你自己的电脑你自己的leargit库。

1、在这个库创建一个dev分支，并且分支里面添加hello.py文件

2、在这里我们

    git add hello.py

    git commit –m ‘add utf-8’

git push origin dev   //将本地仓库dev分支推到远程仓库的dev

发现推送失败：因为你的模拟推送（相当于你的小伙伴）的最新提交和你试图推送的提交有冲突，git提示我们，先用pit pull 把最新的提交从origin/dev抓下来，解决冲突在推送

3、我们使用命令git pull

git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示设置dev和origin/dev链接

4、使用git branch –-set-upstream devorigin/dev  命令设置链接。

5、再使用git pull    成功。（但是合并有冲突，需要解决冲突在提交）

6、使用git status查看状态

在使用命令vi hello.py进行修改，解决冲突

使用vi hello.py命令之后出现下图，图中不小心添加了一些字段，本来是没有的因为手误才有，但是不影响我们这个例子。

7、命令 git add hello.py

        git commit –m ‘merge and fix hello.py’

git push origindev     //推送分支到远程库

推送成功，再次去刷新自己github页面，这也就完成了你和小伙伴的协作

标签管理：

发布一个版本时，就唯一确定了打标签时刻的版本，标签是版本库的一个快照。tag就是一个让人容易记住有意义的名字，它跟着某个commit绑在一起

……..

使用GitHub

GitHub作为免费的远程仓库，如果是个人的开源项目，放到GitHub是完全没有问题的。GitHub也是一个开源协作社区，通过GitHub，既可以让别人参与尼的开源项目，也可以参与别人的开源项目

常见错误解决

3.1如果输入$ git remote add origin git@github.com:xxx（github帐号名）/xxx（项目名）.git

提示出错信息：fatal: remote origin already exists.

解决办法如下：

1、先输入$ git remote rm origin

2、再输入$ git remote add origin git@github.com:djqiang/gitdemo.git 就不会报错了！

3、如果输入$ git remote rm origin 还是报错的话，error: Could not remove config section 'remote.origin'. 我们需要修改gitconfig文件的内容

4、找到你的github的安装路径，我的是C:\Users\ASUS\AppData\Local\GitHub\PortableGit_ca477551eeb4aea0e4ae9fcd3358bd96720bb5c8\etc

5、找到一个名为gitconfig的文件，打开它把里面的[remote "origin"]那一行删掉就好了！

3.2如果输入$ git push origin master

提示出错信息：error:failed to push som refs to .......(此时说明需要先pull,再push)

解决办法如下：

1、先输入$ git pull origin master //先把远程服务器github上面的文件拉下来

2、再输入$ git push origin master

3、如果出现报错 fatal: Couldn't find remote ref master或者fatal: 'origin' does not appear to be a git repository以及fatal: Could not read from remote repository.

4、则需要重新输入$ git remote add origin git@github.com:xxx/xxx.git(如果还有问题，参看前面)

Linux命令：

[if !supportLists]1. [endif]ls查看文件

[if !supportLists]2. [endif]pwd  显示当前的工作目录

[if !supportLists]3. [endif]cd 进入目录

   [例子]： cd回到注册进入时的目录 cd /tmp进入 /tmp 目录 cd ../进入上级目录 

[if !supportLists]4. [endif]mkdir创建目录

5． rmdir  删除目录

6． cat显示文件至标准输出

7．cp拷贝

     [例子]: cp file1 file2将文件 file1 拷贝到文件 file2 8. mv移动

     - i在覆盖已存在文件时作提示，若回答 y 则覆盖，其他则中止

[例子]: 

mv file1 file2将文件 file1 改名为 file2 mv file1 file2 /tmp将文件 file1 和文件 file2 移动到目录 /tmp 下

9. touch创建文件

10.vi编辑

i 插入编辑内容

esc退出编辑

：wq保存并退出