git bisect是一个很有用的命令，用来查找哪一次代码提交引入了错误。 它的原理很简单，就是将代码提交的历史，按照两分法不断缩小定位。所谓"两分法"，就是将代码历史一分为二，确定问题出在前半部分，还是后半部分，不断执行这个过程，直到范围缩小到某一次代码提交。 本文通过一个实例，解释如何使用这个命令。下面是一个代码库，请将它克隆到本地。
|
1 2 3 4 |
$ git clone <a class="token email-link" href="mailto:git@github">git@github</a><span class="token punctuation">.</span>com<span class="token punctuation">:</span>bradleyboy<span class="token operator">/</span>bisectercise<span class="token punctuation">.</span>git $ cd bisectercise |
这个库是一个网页index.html，在浏览器打开这个网页。
|
1 2 3 |
$ open index<span class="token punctuation">.</span>html |
网页上是一个计数器，有两个按钮。点击+号按钮，可以看到计数器没有递增，反而递减，这说明代码有问题。 现在，就要来查找，到底哪一次代码提交，引入了错误。首先，检查一下代码提交历史。
|
1 2 3 |
$ git log <span class="token operator">--</span>pretty<span class="token operator">=</span>oneline |
可以看到，这个库一共有101次提交。最早的第一次提交的哈希是4d83cf。 git bisect start命令启动查错，它的格式如下。
|
1 2 3 |
$ git bisect start <span class="token punctuation">[</span>终点<span class="token punctuation">]</span> <span class="token punctuation">[</span>起点<span class="token punctuation">]</span> |
上面代码中，"终点"是最近的提交，"起点"是更久以前的提交。它们之间的这段历史，就是差错的范围。 这个例子中，我们选择全部的代码历史。起点是第一次提交4d83cf，终点是最近一次的HEAD。当然，指定其他范围也可以。
|
1 2 3 |
$ git bisect start HEAD 4d83cf |
执行上面的命令以后，代码库就会切换到这段范围正当中的那一次提交，本例是第51次提交。 现在刷新浏览器，点击+按钮，发现可以正常递增。使用git bisect good命令，标识本次提交（第51次）没有问题。
|
1 2 3 |
$ git bisect good |
既然第51次提交没有问题，就意味着错误是在代码历史的后半段引入的。执行上面的命令，Git 就自动切换到后半段的中点（第76次提交）。 现在刷新浏览器，点击+按钮，发现不能正常递增。使用git bisect bad命令，标识本次提交（第76）有问题。
|
1 2 3 |
$ git bisect bad |
执行上面的命令以后，Git 就自动切换到第51次到第76次的中点（第63次提交）。 接下来，不断重复这个过程，直到成功找到出问题的那一次提交为止。这时，Git 会给出如下的提示。
|
1 2 3 |
b47892 is the first bad commit |
既然找到那个有问题的提交，就可以检查代码，确定具体是什么错误。 然后，使用git bisect reset命令，退出查错，回到最近一次的代码提交。
|
1 2 3 |
$ git bisect reset |
现在就可以开始修复错误了。 （完） from:http://www.ruanyifeng.com/blog/2018/12/git-bisect.html
View Details用户名和邮箱的作用： 用户名和邮箱地址相当于你的身份标识，是本地Git客户端的一个变量，不会随着Git库而改变。 每次commit都会用用户名和邮箱纪录。 github的contributions跟你的邮箱是有关联的。 查看自己的用户名和邮箱地址： $ git config user.name $ git config user.email 修改自己的用户名和邮箱地址： $ git config --global user.name "xxx" $ git config --global user.email "xxx" from:https://www.cnblogs.com/lxwphp/p/10619618.html
View Details1. 切换到要操作的项目文件夹命令行 cd ProjectPath 2.查看项目分支（包括本地和远程）命令行 git branch -a 3.删除本地分支 git branch -d 分支名 4.删除远程分支 git push origin --delete 分支名 5.查看删除后的分支 git branch -a 引用：https://blog.csdn.net/qq_32452623/article/details/54340749 from:https://blog.csdn.net/u011280600/article/details/80744818
View Details|
1 2 3 4 5 6 7 8 |
暂存区的修改就是已经你已经将文件 add，但是还没有commit的时候。 此时HEAD执行最近一次提交的commit。 放弃暂存区的修改 git reset HEAD 然后可以执行 git diff --cached 比较一下暂存区和最近一次的commit的不同，应该是没有输出的。 |
from:https://blog.csdn.net/weixin_36149892/article/details/86597086
View Details1.查看本地分支
|
1 2 3 |
$ git branch * br-2.1.2.2 master |
2.查看远程分支
|
1 2 3 4 5 |
$ git branch -r origin/HEAD -> origin/master origin/feature/IOS_visualtrack origin/feature/android_visualtrack origin/master |
3.查看所有分支
|
1 2 3 4 5 6 7 8 |
$ git branch -a * br-2.1.2.2 master remotes/origin/HEAD -> origin/master remotes/origin/br-2.1.2.1 remotes/origin/br-2.1.2.2 remotes/origin/br-2.1.3 remotes/origin/master |
4.切换远程分支
|
1 2 3 4 5 6 7 8 9 |
$ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/Release remotes/origin/master $ git checkout -b myRelease origin/Release Branch myRelease set up to track remote branch Release from origin. Switched to a new branch 'myRelease' |
PS:作用是checkout远程的Release分支，在本地起名为myRelease分支，并切换到本地的myRelase分支 5.合并分支 合并前要先切回要并入的分支 以下表示要把issue1234分支合并入master分支
|
1 2 3 4 5 |
$: git checkout master $: git merge issue1234 Merge made by recursive. README | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) |
6.撤消上一次commit的内容(该操作会彻底回退到某个版本，本地的源码也会变为上一个版本的内容) git reset --hard <commit-id> 以下表示要撤消“update build gradle configuration file”这一次的commit id,返回到"add battery settings ui"这一次的commit id,
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
xp.chen@YC-JG-YXKF-PC27 MINGW64 /f/ob ((c8303a9...)) $ git log commit c8303a9e8db2bcf4edb7488e722a380f4e8858ec (HEAD) Author: xp.chen <xp.chen@yuneec.com> Date: Sat Oct 28 09:28:51 2017 +0800 update build gradle configuration file Change-Id: I9ee532fd0d4698613698a64eb754fb98a8559e32 commit 8d8e5ccf24cf6836ab780aa3860270c3876e825a Author: xp.chen <xp.chen@yuneec.com> Date: Sat Oct 28 09:02:01 2017 +0800 add battery settigns ui Change-Id: Ia907ee4e84f54c00a186d31378a7925a6adaba0e xp.chen@YC-JG-YXKF-PC27 MINGW64 /f/ob ((c8303a9...)) $ git reset --hard 8d8e5ccf24cf6836ab780aa3860270c3876e825a HEAD is now at 8d8e5cc add battery settigns ui xp.chen@YC-JG-YXKF-PC27 MINGW64 /f/ob ((8d8e5cc...)) $ git log commit 8d8e5ccf24cf6836ab780aa3860270c3876e825a (HEAD) Author: xp.chen <xp.chen@yuneec.com> Date: Sat Oct 28 09:02:01 2017 +0800 add battery settigns ui Change-Id: Ia907ee4e84f54c00a186d31378a7925a6adaba0e |
7. git commit -m 注释换行 git commit -m 注释可以通过单引号来换行，比如：
|
1 2 3 4 5 6 7 |
$ git commit -m ' > 1.aaaaa > 2.bbbb > ' [master b25154b] 1.aaaaa 2.bbbb 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 ss.txt |
通过git commit --amend 命令可以查看到刚刚的log信息为
|
1 2 |
1.aaaaa 2.bbbb |
from:https://www.cnblogs.com/yongdaimi/p/7600052.html
View Details打标签 像其他版本控制系统（VCS）一样，Git 可以给历史中的某一个提交打上标签，以示重要。 比较有代表性的是人们会使用这个功能来标记发布结点（v1.0 等等）。 在本节中，你将会学习如何列出已有的标签、如何创建新标签、以及不同类型的标签分别是什么。 列出标签 在 Git 中列出已有的标签是非常简单直观的。 只需要输入 git tag：
|
1 2 3 |
$ git tag v0.1 v1.3 |
这个命令以字母顺序列出标签；但是它们出现的顺序并不重要。 你也可以使用特定的模式查找标签。 例如，Git 自身的源代码仓库包含标签的数量超过 500 个。 如果只对 1.8.5 系列感兴趣，可以运行：
|
1 2 3 4 5 6 7 8 9 10 11 |
$ git tag -l 'v1.8.5*' v1.8.5 v1.8.5-rc0 v1.8.5-rc1 v1.8.5-rc2 v1.8.5-rc3 v1.8.5.1 v1.8.5.2 v1.8.5.3 v1.8.5.4 v1.8.5.5 |
创建标签 Git 使用两种主要类型的标签：轻量标签（lightweight）与附注标签（annotated）。 一个轻量标签很像一个不会改变的分支——它只是一个特定提交的引用。 然而，附注标签是存储在 Git 数据库中的一个完整对象。 它们是可以被校验的；其中包含打标签者的名字、电子邮件地址、日期时间；还有一个标签信息；并且可以使用 GNU Privacy Guard （GPG）签名与验证。 通常建议创建附注标签，这样你可以拥有以上所有信息；但是如果你只是想用一个临时的标签，或者因为某些原因不想要保存那些信息，轻量标签也是可用的。 附注标签 在 Git 中创建一个附注标签是很简单的。 最简单的方式是当你在运行 tag 命令时指定 -a 选项：
|
1 2 3 4 5 |
$ git tag -a v1.4 -m "my version 1.4" $ git tag v0.1 v1.3 v1.4 |
-m 选项指定了一条将会存储在标签中的信息。 如果没有为附注标签指定一条信息，Git 会运行编辑器要求你输入信息。 通过使用 git show 命令可以看到标签信息与对应的提交信息：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
$ git show v1.4 tag v1.4 Tagger: Ben Straub <ben@straub.cc> Date: Sat May 3 20:19:12 2014 -0700 my version 1.4 commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon <schacon@gee-mail.com> Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number |
输出显示了打标签者的信息、打标签的日期时间、附注信息，然后显示具体的提交信息。 轻量标签 另一种给提交打标签的方式是使用轻量标签。 轻量标签本质上是将提交校验和存储到一个文件中——没有保存任何其他信息。 创建轻量标签，不需要使用 -a、-s 或 -m 选项，只需要提供标签名字：
|
1 2 3 4 5 6 7 |
$ git tag v1.4-lw $ git tag v0.1 v1.3 v1.4 v1.4-lw v1.5 |
这时，如果在标签上运行 git show，你不会看到额外的标签信息。 命令只会显示出提交信息：
|
1 2 3 4 5 6 |
$ git show v1.4-lw commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon <schacon@gee-mail.com> Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number |
后期打标签 你也可以对过去的提交打标签。 假设提交历史是这样的：
|
1 2 3 4 5 6 7 8 9 10 11 |
$ git log --pretty=oneline 15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment' a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support 0d52aaab4479697da7686c15f77a3d64d9165190 one more thing 6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment' 0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function 4682c3261057305bdd616e23b64b0857d832627b added a todo file 166ae0c4d3f420721acbb115cc33848dfcc2121a started write support 9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile 964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo 8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme |
现在，假设在 v1.2 时你忘记给项目打标签，也就是在 “updated rakefile” 提交。 你可以在之后补上标签。 要在那个提交上打标签，你需要在命令的末尾指定提交的校验和（或部分校验和）：
|
1 |
$ git tag -a v1.2 9fceb02 |
可以看到你已经在那次提交上打上标签了：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
$ git tag v0.1 v1.2 v1.3 v1.4 v1.4-lw v1.5 $ git show v1.2 tag v1.2 Tagger: Scott Chacon <schacon@gee-mail.com> Date: Mon Feb 9 15:32:16 2009 -0800 version 1.2 commit 9fceb02d0ae598e95dc970b74767f19372d61af8 Author: Magnus Chacon <mchacon@gee-mail.com> Date: Sun Apr 27 20:43:35 2008 -0700 updated rakefile ... |
共享标签 默认情况下，git push 命令并不会传送标签到远程仓库服务器上。 在创建完标签后你必须显式地推送标签到共享服务器上。 这个过程就像共享远程分支一样——你可以运行 git push origin [tagname]。
|
1 2 3 4 5 6 7 8 |
$ git push origin v1.5 Counting objects: 14, done. Delta compression using up to 8 threads. Compressing objects: 100% (12/12), done. Writing objects: 100% (14/14), 2.05 KiB | 0 bytes/s, done. Total 14 (delta 3), reused 0 (delta 0) To git@github.com:schacon/simplegit.git * [new tag] v1.5 -> v1.5 |
如果想要一次性推送很多标签，也可以使用带有 --tags 选项的 git push 命令。 这将会把所有不在远程仓库服务器上的标签全部传送到那里。
|
1 2 3 4 5 6 7 |
$ git push origin --tags Counting objects: 1, done. Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done. Total 1 (delta 0), reused 0 (delta 0) To git@github.com:schacon/simplegit.git * [new tag] v1.4 -> v1.4 * [new tag] v1.4-lw -> v1.4-lw |
现在，当其他人从仓库中克隆或拉取，他们也能得到你的那些标签。 删除标签 […]
View Details首先 ，把项目 clone 到其他文件夹下
|
1 |
git clone git@github.com:skyming/BMAdScrollView.git |
然后查看指定历史版本 tree 的 SHA checkout 即可，哎，程序员，需要什么学什么。。。
|
1 |
git checkout b0362a895d39061c0bc6f05c575af47de1b3f702 |
然后就顺利切到指定的分支版本了。。。 from:https://www.cnblogs.com/jiu0821/p/9270145.html
View Details在第三篇时，我们已经成功地添加并提交了一个index.html文件，现在我们继续修改index.html文件，改成如下内容： 现在，运行命令 git status 查看结果： git status命令可以让我们时刻掌握仓库当前的状态， 上面的命令 modified：index.html，输出告诉我们，index.html被修改过了， 需要重新添加文件，（git add命令）； 虽然Git 告诉我们index.html被修改了，如果要查看具体修改了什么内容，怎么办呢？ 如果休假回来，已经记不清上次怎么修改index.html的内容，这时，可以使用命令git diff 来查看： git diff 命令表示查看difference；显示的格式正是Unix通用的diff格式。 可以从上面的命令输出中看到，两行红色字体的内容是修改前的旧内容，而两行绿色字体的内容为修改后的新内容； 现在知道了对index.html作了什么修改后，再把它提交到仓库。提交修改和提交新文件是同样的步骤和操作； 第一步：执行 git add 命令 ；之后再执行 git status命令，看看仓库当前的状态； git status命令可知：可以提交的文件包括index.html，下一步：执行 git commit 命令； 提交之后，再使用 git status 命令 查看仓库当前状态：nothing to commit,working tree clean 表示当前没有需要提交，工作目录是干净的； 小结： git status 命令 表示 查看仓库当前状态； git diff 命令 表示 查看修改内容； 转载来自：https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000 from:https://blog.csdn.net/qq_40415721/article/details/82145156
View Details