Git学习(第七天) 我们在合并分支时，Git会用到”Fast forward“模式，在这种模式下删除分支后会丢掉分支信息。如果我们要强制禁用”Fast forward“模式，Git就会在merge时生存一个新的commit，这样从分支历史上就可以看出分支信息。那么，如何强制禁用”Fast forward“模式呢？在merge时 加上参数 --no-ff 即可。创建并切换一个分支dev：$ git checkout -b dev Switched to a new branch 'dev' 修改readme.txt文件并提交：$ git add readme.txt $ git commit -m '修改readme' [dev c835981] 修改readme 1 file changed, 1 insertion(+) 提交完成后切换至master：$ git checkout master Switched to branch 'master' Your branch is ahead of 'GitGo/master' by 7 commits. (use "git push" to publish your local commits) 现在开始合并dev分支到master，在使用merge时使用--no-ff禁用”Fast forward“：$ git merge --no-ff -m '禁用fast forward方式合并文件' dev Merge made by the 'recursive' strategy. readme.txt | 1 + 1 file changed, 1 insertion(+) 因为本次禁用了”Fast forward“合并会创建一个新的commit，所以在后面加上了-m参数，把commit描述写进去。合并后可以使用git log查看分支历史：$ git log --graph --pretty=oneline --abbrev-commit * 068ed5b (HEAD -> master) 禁用fast forward方式合并文件 |\ | * c835981 (dev) 修改readme |/ * da26543 修改文件内容 |\ | * cfc178e 修改Git为git * | 898bd79 修改文字为繁体字，修改标点符号为英文 |/ * e235cf1 一个新的版本 * 081fd0d 修改后的文件 |\ | * 3b0631c 分支冲突解决学习1 * | 607fe21 修改的今天修改的内容【学习分支冲突解决方法】 |/ * cde8ce3 (GitGo/master) 添加测试文件 * 742b3d0 新增许可证描述文件；修改项目说明文件； * 53b0c21 添加了一段文字 Add Time:2017-01-05 * 4b7b169 修改描述文档 * 068eefe wrote a readme file 可以从上面的操作历史中看到，不使用"Fast forward"模式，merge后就像这样：分支策略：通常在实际的开发中，我们应该按照几个基本原则进行分支管理：首先，master分⽀应该是非常稳定的，也就是仅用来发布新版本，平时不能在上⾯干活；那在哪干活呢？干活都在dev分支上，也就是说，dev分⽀是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分⽀发布1.0版本；你和你的⼩伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。所以，团队合作的分⽀支看起来就像这样：小结Git分支十分强大，在团队开发中应该充分应用。合并分支时，加上--no-ff参数就可以用普模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。BUG分支：软件开发中，产生BUG几乎是我们每天无法避免的一件事。当然，既然有了BUG那就需要修复。比如现有一个BUG需要马上进行修复处理。这个时候，就可以体现出Git中强大的分支管理了。我们可以通过一个临时分支来修复BUG，修复后合并分支，然后将临时分支删除。但接到一个修复的BUG任务，很自然地想到创建一个分支issue-105来修复他，但是我们当前正在dev上进行着开发工作，这部分代码还没有提交：$ git status On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: LICENSE.txt 由于我的功能开发到一半，预计开发完成至少还需要1天，很显然这个未完成的代码是不能提交的。但是目前必须需要在最短的时间内修复这个BUG，怎么办？强大的Git为我们提供了一个stash功能，可以把当前的工作现场”储藏“起来，等以后恢复现场继续工作：$ git stash Saved working directory and index state WIP on dev: c835981 修改readme 现在用git status查看工作区：$ git status On branch dev nothing to commit, working tree clean目前工作区是干净的（除还没有被Git管理的文件），因此可以放心的创建分支来修复Bug。首先得确认修复BUG是在那个分支上。假设我们需要在master上修复该BUG，就在master上创建临时的分支：$ git checkout master Switched to branch 'master' Your branch is ahead of 'GitGo/master' by 11 commits. (use "git push" to publish your local commits) $ git checkout -b issue-105 Switched to a new branch 'issue-105' 修改文件然后提交：$ git add test.txt $ git commit -m '修改BUG' [issue-105 05372b9] 修改BUG 1 file changed, 1 insertion(+), 1 deletion(-) 提交完成后，切换到master分支，合并issue-105分支，合并完成后删除issue-105分支：$ git checkout master Switched to branch 'master' Your branch is ahead of 'GitGo/master' by 11 commits. (use "git push" to publish your local commits) $ git merge --no-ff -m '修复BUG105' issue-105 Merge made by the 'recursive' strategy. test.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) $ git branch -d issue-105 Deleted branch issue-105 (was 05372b9). 好的。BUG105我们已经修复并提交了master了。现在我们需要返回dev继续干刚才没有完成的活。$ git checkout dev Switched to branch 'dev' $ git status On branch dev nothing to commit, working tree clean 工作区我们刚刚在dev修改的文件，哪去了？不要着急。用git stash list 命令查看：$ git stash list stash@{0}: WIP on dev: c835981 修改readmedev的工作现场还在，Git只是把stash内容存放在某个地方了，但是需要恢复一下，有两个方法：1、 使用git stash apply 恢复，但是在恢复后，stash内容并没有删除，需要使用git stash drop 来删除；$ git stash apply On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: LICENSE.txt no changes added to commit (use "git add" and/or "git commit -a") $ git stash drop Dropped refs/stash@{0} (190f697d730a4a7816b3049acf7cf33d6d162162) 2、使用git stash pop，恢复的同时把stash内容也删除了：$ git stash pop On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: LICENSE.txt no changes added to commit (use "git add" and/or "git commit -a") Dropped refs/stash@{0} (62947f8efd82d5b72410cdabd47eaaffa4d53dca) 再用git stash list查看，就看不到任何的stash内容：$ git stash list可以多次stash，恢复的时候先用git stash list查看队列，然后恢复时指定stash序列；stash的队列是按照的时间的先后顺序倒叙排列的（即时间最新的在前，stash@{0}）;存在多个stash在不指明恢复序列，默认为队列第一个。$ git stash list stash@{0}: WIP on dev: c835981 修改readme stash@{1}: WIP on dev: c835981 修改readme stash@{2}: WIP on dev: c835981 修改readme $ git stash apply stash@{1} On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: LICENSE.txt no changes added to commit (use "git add" and/or "git commit -a") $ git stash drop stash@{1} Dropped refs/stash@{1} (159798b0499e0acf7cf33d6d162162a5fff64f0d) 修改BUG时，我们会通过创建新的BUG分支进行修复，然后合并，最后删除；当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复完成后，再git stash pop，重新回到工作现场。

Git学习(第六天) 在项目中，通常会发生多个人对一个文件进行修改，这样在合并分支的时候就很难避免不发生冲突。一旦在我们合并的时候出现冲突，这个时候我们该怎么解决呢？下面以一个例子来演示冲突如何解决：准备一个新的分支：featrue1，继续在新的分支开发：$ git checkout -b feature1 Switched to a new branch 'feature1' 查看当前的工作区指向的是哪个分支：$ git branch * feature1 master 接下来，修改feature1分支中的readme.txt：feature1分支中的readme.txt原来的内容：”Git学习：解决冲突。"（如上图）修改为：”git学习：解决冲突。"(如下图)修改完成后在feature1分支上提交：$ git add readme.txt $ git commit -m '修改Git为git' [feature1 cfc178e] 修改Git为git 1 file changed, 1 insertion(+), 1 deletion(-) 切换到master分支上：$ git checkout master Switched to branch 'master' Your branch is ahead of 'GitGo/master' by 1 commits. (use "git push" to publish your local commits) Git还会自动提示我们当前master分支比远程的master分支要超前1个提交。在master分支上把readme.txt文件的内容进行修改：master分支中的readme.txt原来的内容：”Git学习：解决冲突。"（如上图）修改为：”Git学習:解决冲突."(如下图)在master分支上提交readme.txt文件：$ git add readme.txt $ git commit -m '修改文字为繁体字，修改标点符号为英文' [master 898bd79] 修改文字为繁体字，修改标点符号为英文 1 file changed, 1 insertion(+), 1 deletion(-) 好了，现在master分支和feature1分支各自都分别有新的提交了：这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：$ git merge feature1 Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt Automatic merge failed; fix conflicts and then commit the result. 果然冲突了！Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件：$ git status On branch master Your branch is ahead of 'GitGo/master' by 5 commits. (use "git push" to publish your local commits) You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge) Unmerged paths: (use "git add <file>..." to mark resolution) both modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a") 现在直接查看readme.txt的内容：Git 用<<<<<<<，=======，>>>>>>> 标记出不同分支的内容，我们修改如下后保存：再提交：$ git add readme.txt $ git commit -m '修改文件内容' [master da26543] 修改文件内容 现在，master分支和feature1分支变成了下图所示：用带参数的git log也可以看到分支的合并情况：$ git log --graph --pretty=oneline --abbrev-commit * da26543 (HEAD -> master) 修改文件内容 |\ | * cfc178e (feature1) 修改Git为git * | 898bd79 修改文字为繁体字，修改标点符号为英文 |/ * e235cf1 一个新的版本 * cde8ce3 (GitGo/master) 添加测试文件 * 742b3d0 新增许可证描述文件；修改项目说明文件； * 53b0c21 添加了一段文字 Add Time:2017-01-05 * 4b7b169 修改描述文档 * 068eefe wrote a readme file 当我们合并分支解决完冲突之后，删除feature1分支：$ git branch -d feature1 Deleted branch feature1 (was cfc178e). OK，到这里为止，在进行分支合并中出现的冲突就算是解决完成了。总结：1、当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。2、解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。3、用git log --graph命令可以看到分支合并图。

Git学习(第五天) Git分支管理分支就是美国科幻大片里面的平行空间，当你正在电脑前努力学习Git的时候，另一个你正在另一个平行宇宙里努力学习SVN。两个平行空间互不干扰。但是在某个时间，两个空间合并了。然后你就学会的两个技能Git和SVN。分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。首先，需要了解Git分支内部是怎么运作的。在版本回退中，每次提交Git都它们串成一条时间线，这条时间就是一个分支，这个分支叫主分支master。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：每次提交，master分支都会向前移动异步，这样，随着你不断提交，master分支的线也越来越长。当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向就表示当前分支在dev上：你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化。不过，从现在开始，对工作区的修改和提交就是针对dev分支了。比如新提交一次后，dev指针往前移动一步，而master指针不变：假如我们在dev上工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：所以Git合并分支也很快~ 就改改指针，工作区内容也不变~合并完成支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删除，删掉后，我们就剩下了一条master分支：真实太神奇了，你看的出来有些提交时通过分支完成的吗？下面开始实战。首先，我们创建dev分支，然后切换到dev分支：$ git checkout -b dev Switched to a new branch 'dev'git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：$ git branch dev $ git checkout dev Switched to branch 'dev'然后，用git branch命令查看当前分支：$ git branch * dev   mastergit branch命令会列出所有分支，当前分支前面会标一个*号。然后，我们就可以在dev分支上正常提交，比如对readme.txt做个修改，加上一行：Creating a new branch is quick.然后提交：$ git add readme.txt $ git commit -m "branch test" [dev fec145a] branch test  1 file changed, 1 insertion(+)现在，dev分支的工作完成，我们就可以切换回master分支：$ git checkout master Switched to branch 'master'切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：现在，我们把dev分支的工作成果合并到master分支上：$ git merge dev Updating d17efd8..fec145a Fast-forward readme.txt | 1 + 1 file changed, 1 insertion(+)git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。合并完成后，就可以放心地删除dev分支了：$ git branch -d dev Deleted branch dev (was fec145a). 删除后，查看branch，就只剩下master分支了： $ git branch * master因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。命令总结：在Git中鼓励大量使用分支：查看分支：git branch创建分支：git branch <name>切换分支：git checkout <name>创建+切换分支：git checkout -b <name>合并某分支到当前分支：git merge <name>删除分支：git branch -d <name> 

git命令-远程仓库拉取、本地仓库更新、工作空间提交等常用 收藏贴~，需要的可以收藏啦~  Workspace：工作区  Index / Stage：暂存区  Repository：仓库区（或本地仓库）  Remote：远程仓库一、新建代码库  # 在当前目录新建一个Git代码库  $ git init  # 新建一个目录，将其初始化为Git代码库  $ git init[project-name]  # 下载一个项目和它的整个代码历史  $ git clone [url]二、配置Git的设置文件为.gitconfig，它可以在用户主目录下（全局配置），也可以在项目目录下（项目配置）。  # 显示当前的Git配置  $ git config--list  # 编辑Git配置文件  $ git config -e[--global]  # 设置提交代码时的用户信息  $ git config[--global] user.name "[name]"  $ git config[--global] user.email "[email address]"三、增加/删除文件  # 添加指定文件到暂存区  $ git add [file1][file2] ...  # 添加指定目录到暂存区，包括子目录  $ git add [dir]  # 添加当前目录的所有文件到暂存区  $ git add .  # 添加每个变化前，都会要求确认  # 对于同一个文件的多处变化，可以实现分次提交  $ git add -p  # 删除工作区文件，并且将这次删除放入暂存区  $ git rm [file1][file2] ...  # 停止追踪指定文件，但该文件会保留在工作区  $ git rm --cached[file]  # 改名文件，并且将这个改名放入暂存区  $ git mv[file-original] [file-renamed]四、代码提交  # 提交暂存区到仓库区  $ git commit -m[message]  # 提交暂存区的指定文件到仓库区  $ git commit[file1] [file2] ... -m [message]  # 提交工作区自上次commit之后的变化，直接到仓库区  $ git commit -a  # 提交时显示所有diff信息  $ git commit -v  # 使用一次新的commit，替代上一次提交  # 如果代码没有任何新变化，则用来改写上一次commit的提交信息  $ git commit--amend -m [message]  # 重做上一次commit，并包括指定文件的新变化  $ git commit--amend [file1] [file2] ...五、分支  # 列出所有本地分支  $ git branch  # 列出所有远程分支  $ git branch -r  # 列出所有本地分支和远程分支  $ git branch -a  # 新建一个分支，但依然停留在当前分支  $ git branch[branch-name]  # 新建一个分支，并切换到该分支  $ git checkout -b[branch]  # 新建一个分支，指向指定commit  $ git branch[branch] [commit]  # 新建一个分支，与指定的远程分支建立追踪关系  $ git branch--track [branch] [remote-branch]  # 切换到指定分支，并更新工作区  $ git checkout[branch-name]  # 切换到上一个分支  $ git checkout -  # 建立追踪关系，在现有分支与指定的远程分支之间  $ git branch--set-upstream [branch] [remote-branch]  # 合并指定分支到当前分支  $ git merge[branch]  # 选择一个commit，合并进当前分支  $ git cherry-pick[commit]  # 删除分支  $ git branch -d[branch-name]  # 删除远程分支  $ git push origin--delete [branch-name]  $ git branch -dr[remote/branch]六、标签  # 列出所有tag  $ git tag  # 新建一个tag在当前commit  $ git tag [tag]  # 新建一个tag在指定commit  $ git tag [tag][commit]  # 删除本地tag  $ git tag -d[tag]  # 删除远程tag  $ git push origin:refs/tags/[tagName]  # 查看tag信息  $ git show [tag]  # 提交指定tag  $ git push[remote] [tag]  # 提交所有tag  $ git push[remote] --tags  # 新建一个分支，指向某个tag  $ git checkout -b[branch] [tag]七、查看信息  # 显示有变更的文件  $ git status  # 显示当前分支的版本历史  $ git log  # 显示commit历史，以及每次commit发生变更的文件  $ git log --stat  # 搜索提交历史，根据关键词  $ git log -S[keyword]  # 显示某个commit之后的所有变动，每个commit占据一行  $ git log [tag]HEAD --pretty=format:%s  # 显示某个commit之后的所有变动，其"提交说明"必须符合搜索条件  $ git log [tag]HEAD --grep feature  # 显示某个文件的版本历史，包括文件改名  $ git log --follow[file]  $ git whatchanged[file]  # 显示指定文件相关的每一次diff  $ git log -p[file]  # 显示过去5次提交  $ git log -5--pretty --oneline  # 显示所有提交过的用户，按提交次数排序  $ git shortlog-sn  # 显示指定文件是什么人在什么时间修改过  $ git blame[file]  # 显示暂存区和工作区的差异  $ git diff  # 显示暂存区和上一个commit的差异  $ git diff--cached [file]  # 显示工作区与当前分支最新commit之间的差异  $ git diff HEAD  # 显示两次提交之间的差异  $ git diff[first-branch]...[second-branch]  # 显示今天你写了多少行代码  $ git diff--shortstat "@{0 day ago}"  # 显示某次提交的元数据和内容变化  $ git show[commit]  # 显示某次提交发生变化的文件  $ git show--name-only [commit]  # 显示某次提交时，某个文件的内容  $ git show[commit]:[filename]  # 显示当前分支的最近几次提交  $ git reflog八、远程同步  # 下载远程仓库的所有变动  $ git fetch[remote]  # 显示所有远程仓库  $ git remote -v  # 显示某个远程仓库的信息  $ git remote show[remote]  # 增加一个新的远程仓库，并命名  $ git remote add[shortname] [url]  # 取回远程仓库的变化，并与本地分支合并  $ git pull[remote] [branch]  # 上传本地指定分支到远程仓库  $ git push[remote] [branch]  # 强行推送当前分支到远程仓库，即使有冲突  $ git push[remote] --force  # 推送所有分支到远程仓库  $ git push[remote] --all九、撤销  # 恢复暂存区的指定文件到工作区  $ git checkout[file]  # 恢复某个commit的指定文件到暂存区和工作区  $ git checkout[commit] [file]  # 恢复暂存区的所有文件到工作区  $ git checkout .  # 重置暂存区的指定文件，与上一次commit保持一致，但工作区不变  $ git reset[file]  # 重置暂存区与工作区，与上一次commit保持一致  $ git reset--hard  # 重置当前分支的指针为指定commit，同时重置暂存区，但工作区不变  $ git reset[commit]  # 重置当前分支的HEAD为指定commit，同时重置暂存区和工作区，与指定commit一致  $ git reset--hard [commit]  # 重置当前HEAD为指定commit，但保持暂存区和工作区不变  $ git reset--keep [commit]  # 新建一个commit，用来撤销指定commit  # 后者的所有变化都将被前者抵消，并且应用到当前分支  $ git revert[commit]  # 暂时将未提交的变化移除，稍后再移入  $ git stash  $ git stash pop十、其他  # 生成一个可供发布的压缩包  $ git archive

Git学习(第四天) Git操作远程仓库1、添加/连接远程仓库：要操作Git的远程仓库的前提，那就是要先添加或者说是连接远程仓库才行。Git仓库之间的传输都是通过SSH加密的，所以在操作远程库之前，需要做一些准备，首先你需要注册一个 GitHub 或者 GitOSC，下面我用GitOSC来做演示了：1、创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：$ ssh-keygen -t rsa -C "baikeyang@vip.qq.com" Generating public/private rsa key pair. Enter file in which to save the key (/c/Users/lenovo/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /c/Users/lenovo/.ssh/id_rsa. Your public key has been saved in /c/Users/lenovo/.ssh/id_rsa.pub. The key fingerprint is: SHA256:2y8XeQcc8Yjp9cU/cjBeK4kogLtdqd4uWgIRaoTDZug baikeyang@vip.qq.com The key's randomart image is: +---[RSA 2048]----+ |+o .. | |*+. . o.+ | |=+ . . o+oo+| |.E. . . . ..o.B.+| | . . +S. ..* =o| | . o o .o o = o| | o + . . o . | | +.. ... | | ...oo o. | +----[SHA256]-----+ 我这里是一路回车的，由于这个Key是用于个人，所以也无需设置密码。现在就可以根据上面的提示或者自己在用户的主目录中找到 id_rsa 和 id_rsa.pub 两个文件了。这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。2、登录GitOSC，进入个人中心，进入SSH公钥页面；然后填写任意 公钥标题(Key)，在公钥(value)文本框里粘贴id_rsa.pub文件的内容：以上信息都填写完成后，点击确定。SSH 公钥添加成功。为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。通常我们已经在本地创建了一个Git仓库后，又想在GitOSC 创建一个Git仓库，并且让这两个仓库进行远程同步，这样，GitOSC 上的仓库既可以作为备份，又可以让其他人通过该仓库来协作，真是一举多得。3、上面的操作做完了，我们就可以开始添加远程库了。在GitOSC上面新建一个版本库OK，现在已经成功的创建了一个仓库。在仓库创建完成，目前GitOSC 上的仓库是空的，GitOSC给出了一些提示，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitOSC 仓库。现在，我们根据GitOSC 的提示，在本地的仓库下运行命令：$ git remote add GitGo git@git.oschina.net:Mr.bai/GitGo.git添加后，远程库的名字就是GitGo，这是Git默认的叫法，也可以改成别的，但是GitGo这个名字一看就知道是远程库。接着就将本地的版本库 内容推送到远程的版本库中：$ git push -u GitGo master Counting objects: 16, done. Delta compression using up to 4 threads. Compressing objects: 100% (11/11), done. Writing objects: 100% (16/16), 1.48 KiB | 0 bytes/s, done. Total 16 (delta 3), reused 0 (delta 0) To git@git.oschina.net:Mr.bai/GitGo.git * [new branch] master -> master Branch master set up to track remote branch master from GitGo. 把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。 由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。推送成功后，可以立刻在GitOSC 页面中看到远程库的内容已经和本地一模一样：从现在起，只要本地作了提交，就可以通过命令：$ git push origin master把本地master分支的最新修改推送至GitOSC ，现在，你就拥有了真正的分布式版本库！注：SSH警告当你第一次使用Git的clone或者push命令连接GitOSC 时，会得到一个警告：The authenticity of host 'git.oschina.net (xx.xx.xx.xx)' can't be established. RSA key fingerprint is xx.xx.xx.xx.xx. Are you sure you want to continue connecting (yes/no)? 这是因为Git使用SSH连接，而SSH连接在第一次验证GitOSC服务器的Key时，需要你确认GitOSC 的Key的指纹信息是否真的来自GitOSC 的服务器，输入yes回车即可。Git会输出一个警告，告诉你已经把GitOSC 的Key添加到本机的一个信任列表里了：Warning: Permanently added 'git.oschina.net' (RSA) to the list of known hosts.这个警告只会出现一次，后面的操作就不会有任何警告了。如果你实在担心有人冒充GitOSC 服务器，输入yes前可以对照GitOSC的RSA Key的指纹信息是否与SSH连接给出的一致。从远程库克隆：可以重新创建一个新的仓库 或者 找一个仓库，在创建的时候勾选ReadMe，GitOSC会自动为我们创建一个README.md文件。创建完毕后，可以看到README.md文件OK，仓库创建完成。现在，远程库已经准备好了，下一步是用命令git clone克隆一个本地库：$ git clone git@git.oschina.net:Mr.bai/GitClone.git Cloning into 'GitClone'... remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0) Receiving objects: 100% (3/3), done. Checking connectivity... done.如果有多个人协作开发，那么每个人各自从远程克隆一份就可以了。你也许还注意到，GitHub给出的地址不止一个，还可以用https://git.oschina.net/Mr.bai/GitClone.git这样的地址。实际上，Git支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。操作总结：要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；关联后，使用命令git push -u origin master第一次推送master分支的所有内容；此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在，也就是有没有联网都可以正常工作，而SVN在没有联网的时候是拒绝干活的！当有网络的时候，再把本地提交推送一下就完成了同步，真是太方便了！要克隆一个仓库，首先必须知道仓库的地址，然后使用git clone命令克隆。Git支持多种协议，包括https，但通过ssh支持的原生git协议速度最快。

Git学习(第三天) Git管理修改：Git跟踪并管理的是修改，而非文件。比如你新增了一行，这就是一个修改，删除了一行，也是一个修改，更改了某些字符，也是一个修改，删了一些又加了一些，也是一个修改，甚至创建一个新文件，也算一个修改。下面一个小例子来说明： 修改Hello Git.txt，在里面添加一行Hello Git. This is a Git Test File; Time:2017-01-08然后添加到暂存区，然后查看版本库状态：$git add Hello\ Git.txt $git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: Hello Git.txt 然后再修改Hello Git.txt：Hello Git. This is a Git Test File; Time:2017-01-08 11：30(PM) 接着开始提交，继续查看状态：$ git commit -m "添加了文件编辑时间" [master c45bba6] 添加了文件编辑时间 1 file changed, 1 insertion(+), 2 deletions(-) $ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: Hello Git.txt no changes added to commit (use "git add" and/or "git commit -a") 现在我们会发现还是有未被提交的文件。当你用git add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交可以使用git diff HEAD -- Hello\ Git.txt命令查看本地和版本库最新版本的差异：$ git diff HEAD -- Hello\ Git.txt diff --git a/Hello Git.txt b/Hello Git.txt index a17535e..3bfb6e5 100644 --- a/Hello Git.txt +++ b/Hello Git.txt @@ -1,3 +1,3 @@ Hello Git. This is a Git Test File; -Time:2017-01-08 \ No newline at end of file +Time:2017-01-08(PM) \ No newline at end of file 由此可以看到第二次修改的确实没有提交。那怎么提交第二次修改呢？可以继续git add再git commit，也可以别着急提交第一次修改，先git add第二次修改，再git commit，就相当于把两次修改合并后一块提交了：第一次修改 -> git add -> 第二次修改 -> git add -> git commit我们每次修改后，如果不add到暂存区，那就不会加入到commit中。Git撤销修改:我们有时候在对文件编辑后，需要撤销修改。使用 git checkout -- file可以丢弃工作区的修改一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。总之，就是让这个文件回到最近一次git commit或git add时的状态。git checkout -- file命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令，我们在后面的分支管理中会再次遇到git checkout命令。当add到暂存区，但是在commit之前发现提交的文件里面有问题，需要撤销暂存区，重新放到工作区：$git reset HEAD readme.txtgit reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。如果需要丢弃工作区的修改：$ git checkout -- readme.txt场景重现：场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file。场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD file，就回到了场景1，第二步按场景1操作。场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。现在，假设你不但改错了东西，还从暂存区提交到了版本库，怎么办呢？还记得版本回退一节吗？可以回退到上一个版本。不过，这是有条件的，就是你还没有把自己的本地版本库推送到远程。还记得Git是分布式版本控制系统吗？我们后面会讲到远程版本库，一旦你把“stupid boss”提交推送到远程版本库，你就真的惨了……Git删除文件：一般情况下，你通常直接在文件管理器中把没用的文件删了，或者用rm命令删了：$ rm test.txt这个时候，仅仅是将本地工作区中文件删除掉了。版本库该文件还存在。1、如果确实从版本库中删除该文件，可以使用git rm删除，并且git commit：$ git rm test.txt rm 'test.txt' $ git commit -m "delete file" [master a4a701a] delete file 1 file changed, 1 deletion(-) delete mode 100644 test.txt 现在文件在版本库中就被删除了。2、如果删除错了，想恢复可以使用 git checkout -- file命令恢复到文件的最新版本：$ git checkout -- test.txtgit checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。只要文件被提交到版本库就不用担心文件误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。命令：git diff HEAD -- <file> : 查看本地和版本库最新版本的差异git checkout -- <file>： 丢弃工作区的修改git reset HEAD <file>： 丢弃暂存区时rm <file>：本地删除文件git rm <file>：版本库删除文件（git commit  配合 ）