Git Gui 设置语言为中文 Git Gui的英文界面如下：那么如何将该界面从英文切换到中文呢？在Git的安装目录中找到路径 \mingw64\share\git-gui\lib ，如下：如果lib目录中没有 msgs 目录和zh_cn.msg文件的（有的版本是直接把zh_cn.msg放在lib目录下），就手动创建该目录。如果有则无需创建。下载Git Gui语言文件：https://github.com/stayor/git-gui-zh下载好 Git Gui语言文件 后，将zh_cn.msg文件放入刚刚的msgs 目录中，如下：然后再次打开Git Gui，界面已经显示为中文。如下：

[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