搜索到
14
篇与
Git
的结果
-
-
[Git]OpenSSL SSL_read: Connection was reset, errno 10054 早上再从Github上面clone代码的时候，提示 OpenSSL SSL_read: Connection was reset 。karry_bai@XA-Karry_Bai MINGW64 /f/Git $ git clone https://github.com/stayor/git-gui-zh.git Cloning into 'git-gui-zh'... fatal: unable to access 'https://github.com/stayor/git-gui-zh.git/': OpenSSL SSL_read: Connection was reset, errno 10054 经过一番资料查询，发现多数情况下国内访问 Github 会被和谐，有时候网络波动问题会导致推送失败。推荐使用 SSH 方式拉去代码或者参考 开源项目 修改本机 hosts 文件解决访问问题发现是Git开启了SSL认证。关闭SSL认证即可解决这个问题。解决办法：1、解除SSL认证git config --global http.sslVerify "false"2、更新DNS缓存ipconfig /flushdns3、文件过大，超过上限git config http.postBuffer 52428800034、用户名，邮箱问题查看用户名，邮箱git config user.name git config user.email修改，用户名，邮箱git config --global user.name "xxx" git config --global user.email "xxx"移除仓库，重新添加git remote rm origin git remote add origin https://github.com/XXX扩展资料：HelloGitHub 镜像站：https://raw.hellogithub.com/无需安装即可加快访问 GitHub 的方法，修改本地域名解析： https://raw.hellogithub.com/hosts
-
Git学习(第八天) Feature分支:通常添加一个新功能，我们可定不希望因为一些实验性的代码而把分支搞乱，所以每添加一个功能最好是建一个feature分支，在feature分支上面开发、实验，完成后根据需要进行合并，最后删除该featrue分支。下面，举例一个场景： 在工作中，当我们接到一个新的功能，该功能计划于下一个开发版本中。开始准备开发。1、创建分支$git checkout -b feature-car2、快速的开发完毕，提交代码$git add NewCarController.java $git commit -m '新车辆档案' 3、切回dev，合并到dev分支上$git checkout dev在这里的合并和其他分支的合并、删除是一样的。就在合并的此时，接到了上级的命令，因为合同问题，该功能被砍掉不需要了。这个分支也包含了一些比较重要的代码，既然不需要了还是需要就地销毁的4、删除feature分支$git branch -d feature-car error: The branch 'feature-car' is not fully merged. If you are sure you want to delete it, run 'git branch -D feature-car'.咦？提示删除失败报错了？还好Git友情提示，feature-car分支还没有被合并，如果删除将丢失掉该分支的所有修改，如果要强行删除，需要使用大写的-D参数。好了，现在我们强行删除$git branch -D featrue-car总结：开发一个新的功能，最好是新建一个分支，如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除。多人协作:从远处仓库克隆时，实际上git自动将本地的master分支与远程的master分支对应起来了，并且远程仓库的默认名是origin。 查看远程仓库信息使用git remote 或 用查看信息更详细的 git remote -v$ git remote GitGo $ git remote -v GitGo git@git.oschina.net:Mr.bai/GitGo.git (fetch) GitGo git@git.oschina.net:Mr.bai/GitGo.git (push) 上面显示的抓取和推送的地址，没有推送权限的就看不到push地址。推送分支把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上$ git push GitGo master如果要推送其他分支$ git push GitGo dev当然，也并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？master分支是主分支，因此要时刻与远程同步；dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，根据你的需要而定。 抓取分支在多人协作开发时，大家都会往master和dev分支上推送各自的修改。当我们从远程库克隆一个项目，默认情况下只能看到本地的master。可以使用git bransh查看。然后现在你的小伙伴需要在dev分支上开发，就必须创建远程的origin和dev分支到本地，于是他用git checkout -b dev origin/dev 命令创建本地dev分支，他就可以在dev上继续修改，然后时不时的把dev分支push到远程。$ git add test.txt $ git commit -m 'add Test.txt' $ git push origin dev 你的小伙伴向origin/dev分支推送了他的提交，而碰巧你也对同样的文件做了修改，并试图推送$ git add test.txt $ git commit -m 'add test.txt' $ git push origin dev Togithub.com:KerryPak/learngit.git ! [rejected] dev -> dev (non-fast-forward) error: failed to push some refs to 'git@github.com:KerryPak/learngit.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送$ git pull There is no tracking information for the current branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull <remote> <branch> If you wish to set tracking information for this branch you can do so with: git branch --set-upstream-to=origin/<branch> dev git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接$ git branch --set-upstream-to=origin/dev dev Branch 'dev' set up to track remote branch 'dev' from 'origin'. 再pull$ git pull Auto-merging test.txt CONFLICT (add/add): Merge conflict in test.txt Automatic merge failed; fix conflicts and then commit the result. 这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push$ git commit -m "fix test conflict" [dev 57c53ab] fix test conflict $ git push origin dev Counting objects: 6, done. Delta compression using up to 4 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (6/6), 621 bytes | 621.00 KiB/s, done. Total 6 (delta 0), reused 0 (delta 0) To github.com:michaelliao/learngit.git 7a5e5dd..57c53ab dev -> dev 因此，多人协作的工作模式通常是这样：1、首先，可以试图用git push origin <branch-name>推送自己的修改；2、如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；3、如果合并有冲突，则解决冲突，并在本地提交；4、没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。这就是多人协作的工作模式，一旦熟悉了，就非常简单。小结：1、查看远程库信息，使用git remote -v；2、本地新建的分支如果不推送到远程，对其他人就是不可见的；3、从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；4、在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；5、建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；6、从远程抓取分支，使用git pull，如果有冲突，要先处理冲突Rebase在版本库中，经过我们一次次的合并push之后，分子就变成了下面这个样子$ git log --graph --pretty=oneline --abbrev-commit * d1be385 (HEAD -> master, origin/master) init hello * e5e69f1 Merge branch 'dev' |\ | * 57c53ab (origin/dev, dev) fix env conflict | |\ | | * 7a5e5dd add env | * | 7bd91f1 add new env | |/ * | 12a631b merged bug fix 101 |\ \ | * | 4c805e2 fix bug 101 |/ / * | e1e9c68 merge with no-ff |\ \ | |/ | * f52c633 add merge |/ * cf810e4 conflict fixed 对于有强迫症的人来说可能会看起来很乱。Git有一种称为rebase的操作，有人把它翻译成“变基”，将分支中的所有提交(commit)合并都调整合并(应用)在分支的基线上。 想让分支历史看起来像没有经过任何合并一样，你也许可以用 git rebase$ git checkout dev $ git rebase origin这些命令会把你的"dev"分支里的每个提交(commit)取消掉，并且把它们临时 保存为补丁(patch)(这些补丁放到".git/rebase"目录中),然后把"mywork"分支更新 为最新的"origin"分支，最后把保存的这些补丁应用到"dev"分支上。《rebase 前》《rebase 中》当'dev'分支更新之后，它会指向这些新创建的提交(commit),而那些老的提交会被丢弃。 如果运行垃圾收集命令(pruning garbage collection), 这些被丢弃的提交就会删除. （请查看 git gc)《rebase 后》好了，我们现在再次查看一下git log$ git log --graph --pretty=oneline --abbrev-commit * 7e61ed4 (HEAD -> master) add author * 3611cfe add comment * f005ed4 (origin/master) set exit=1 * d1be385 init hello ... 这就是rebase操作的特点：把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了。最后，通过push操作把本地分支推送到远程$ git push origin master 远程分支的提交历史现在也是一条直线啦。在rebase的过程中，也许会出现冲突(conflict). 在这种情况，Git会停止rebase并会让你去解决 冲突；在解决完冲突后，用"git-add"命令去更新这些内容的索引(index), 然后，你无需执行 git-commit,只要执行:$ git rebase --continue 这样git会继续应用(apply)余下的补丁。在任何时候，你可以用--abort参数来终止rebase的行动，并且"mywork" 分支会回到rebase开始前的状态。$ git rebase --abort 小结：1、rebase操作可以把本地未push的分叉提交历史整理成直线；2、rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。
-
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如何将本地仓库推送到远程仓库上 当我们本地仓库的项目开发完成需要将本地仓库内容推送到远程仓库上去，这个时候该如何操作呢？1、先需要将本地仓库关联到远程库：git remote add origin <url>。如：$ git remote add origin git@gitee.com:Mr.bai/Flyway_demo.git2、获取远程仓库并将其与本地仓库进行合并（如果远程库不为空必须做这一步，否则后面的提交会失败）$ git pull –rebase origin master把本地仓库的内容推送到远程，使用git push 命令。实际上是把当前分支master推送到远程。执行此命令后会要求输入用户名、密码，验证通过后即开始上传。$ git push -u origin master或$ git push
-
git删除remote 1、在项目中有两个或多个remote，如何删除多余的remote$ git remote -v FlywayDemo git@gitee.com:Mr.bai/Flyway_demo_test.git (fetch) FlywayDemo git@gitee.com:Mr.bai/Flyway_demo_test.git (push) origin git@gitee.com:Mr.bai/Flyway_demo.git (fetch) origin git@gitee.com:Mr.bai/Flyway_demo.git (push)删除其中指定的FlywayDemo，方法为：git remote remove <name>删除remote的命令中remove可以缩写为rm：git remote rm <name>执行命令后，再次查看remote：$ git remote remove FlywayDemo $ git remote -v origin git@gitee.com:Mr.bai/Flyway_demo.git (fetch) origin git@gitee.com:Mr.bai/Flyway_demo.git (push) 扩展：1、添加remote远程仓库地址的命令：git remote add <name> <url>例子：$ git remote add origin git@gitee.com:Mr.bai/Flyway_demo.git2、修改remote更换远程仓库地址命令，把<URL>更换为新的url地址的：git remote set-url <name> <URL>例子：git remote set-url remote git@gitee.com:Mr.bai/Flyway_demo_test.git还可以通过编辑config配置来修改remote远程仓库地址。config在.get目录下（.git目录为隐藏目录）。有时候我们可能想要把本地的git库，既push到github上，又push到开源中国的Git@OSC上，怎么解决呢。 有人可能会用两个甚至多个远程库，即再添加一个远程库git remote add origin2; 这个方法很低效，因为你要git push 两次才能完成push到两个库。其实还有一个方法就可以搞定这个问题，git的一个远程库 可以对应多个地址，即我能让 远程库origin拥有多个url地址。假设我现在要增加2个远程库地址，分别为：git@gitee.com:Mr.bai/Flyway_demo2.git git@gitee.com:Mr.bai/Flyway_demo3.git由于刚刚已经添加过一个远程库了，所以现在直接添加第二个远程库git remote set-url --add origin git@gitee.com:Mr.bai/Flyway_demo2.git添加第三个远程库git remote set-url --add origin git@gitee.com:Mr.bai/Flyway_demo3.git如果还有多个，依次类推继续添加就是 git remote set-url --add origin <url>操作完成后我们再次查看remote信息：$ git remote set-url --add origin git@gitee.com:Mr.bai/Flyway_demo2.git $ git remote set-url --add origin git@gitee.com:Mr.bai/Flyway_demo3.git $ git remote -v origin git@gitee.com:Mr.bai/Flyway_demo.git (fetch) origin git@gitee.com:Mr.bai/Flyway_demo.git (push) origin git@gitee.com:Mr.bai/Flyway_demo2.git (push) origin git@gitee.com:Mr.bai/Flyway_demo3.git (push) git remote set-url --add origin 就是往当前git项目的config文件里增加一行记录，每执行一次git remote set-url --add origin 就会增加一行。我们也可以使用git config -e 来打开config文件进行手动编辑：所以说，可以直接在config里面直接添加url来修改也是可以的，不必去执行git命令。有几点需要注意：使用git push origin master时，你可以push到origin的多个url地址，但是使用 git pull时，只能拉取origin里的一个url地址，这个fetch-url默认为你添加的到origin的第一个地址，如果你想更改，只需要更改config文件里那三个url的顺序即可，fetch-url会直接对应排行第一的那个url连接。
-
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 warning:LF will be replaced by CRLF in readme.txt 的原因与解决方案 今天用Git Bash 时，在add文件时出现了一个警告。在网上也找到了一些解决方案。再这里总结一下：首先问题出在操作系统上面，不同的操作系统所使用的换行符是不一样的。Uinx、Linux采用的换行符LF表示下一行（LF：LineFeed，中文意思就是换行）；Dos 和 Windows 采用的回车+换行CRLF表示下一行（CRLF：CarriageReturn LineFeed，中文意思就是回车换行）；Mac OS采用的是回车CR表示下一行（CR：CarriageReturn，中文意思就是回车）。在Git中，可以通过下面的命令来设置当前你的Git中采取哪种处理换行的方式：$ git config core.autocrlf此命令会有三个输出，"true"，"false"，"input"输出为true时，Git会将你add的所有文件视为文本文件，将结尾的CRLF转换为LF，而checkout时会再将文件的LF格式转为CRLF格式。输出为false时，line endings不做任何改变，文本文件保持其原来的样子。输出为input时，add时Git会把CRLF转换为LF，而check时仍旧为LF，所以Windows操作系统不建议设置此值。解决办法：将core.autocrlf设为false即可解决这个问题，不过如果你和你的伙伴只工作于Windows平台或者Linux平台，那么没问题，不过如果是存在跨平台的现象的话，还是需要考虑一下。 但当 core autocrlf为true时，还有一个需要慎重的地方，当你上传一个二进制文件，Git可能会将二进制文件误以为是文本文件，从而也会修改你的二进制文件，从而产生隐患。修改autocrlf的命令，以改为true为例：$ git config --global core.autocrlf true #true的位置放你想使autocrlf成为的结果，true，false或者input
-
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 配合 ）
![[Git]OpenSSL SSL_read: Connection was reset, errno 10054](/usr/uploads/2018/05/1bcf6c3ee2d95cbbb05f9f30c6d76b3f.png)
