概述 使用Git时,有时候不同分支的文件是不同步的,因此如果想要把别的分支的文件改动应用到当前分支,应该怎么操作呢?如果两边都有更新,该如何选择合并呢?...这篇小文会对不同情形下的合并进行一个简单的介绍。 引入 假设我们当前在分支branch1, 需要将分支branch2上的a.py合并到当前分支。...上的文件包含在branch2的内容里,那么采用上面的命令也还是可以的: git checkout branch2 -- a.py 另外如果只想合并branch2上的文件的一部分更新到branch1,可以在...chekcout后面增加-p或者--patch选项,交互式地选择要合并过来的代码块: git checkout -p branch2 -- a.py 交互式地操作命令同git add -p,可以参考这里的文章...更复杂的情况是,分支branch1也有同名文件,且也有更新,如果直接使用git checkout的话,分支branch2上的文件会替代本地的文件,且没有任何提示(毕竟cheeckout的含义就是切换到某个分支
问题点描述: 我新建一个线程,并在这个线程中,把某个控件的父级去掉或者更改,导致报这个异常 网上的解析如下: “Windows 窗体”使用单线程单元 (STA) 模型,因为“Windows 窗体...STA 模型要求需从控件的非创建线程调用的控件上的任何方法必须被封送到(在其上执行)该控件的创建线程。...如果您在控件中为大量占用资源的任务使用多线程,则用户界面可以在背景线程上执行一个大量占用资源的计算的同时保持可响应。 用人话描述为:控件是属于主线程(UI线程),不可以跨线程修改其父级。...this.Controls.Add(tb); } } 看起来感觉很绕,而且很麻烦,又要新建方法,又要新建委托 所以我把它简化如下: //使用拉姆达表达式创建一个委托,委托里面修改控件的父级...,委托里面再修改控件的父级 new Thread(() => this.Invoke(delega1)).Start(); }
" 分支 无法删除当前所在的分支 如果某个分支上有任何其他分支上都没有包含的 commit(也就是这个 commit 是要被删除的分支独有的),git 不会删除该分支。...快进合并将使当前检出的分支向前移动,直到它指向与另一个分支指向的 commit 一样为止。...git merge 指令用来合并 git 分支,它将: 查看将合并的分支 查看分支的历史记录并寻找两个分支的 commit 历史记录中都有的单个 commit 将单个分支上更改的代码行合并到一起 提交一个...合并 commit 具有两个父级。对于合并 commit,^ 引用用来表示第一个父 commit,而 ^2 表示第二个父 commit。...第一个父 commit 是当你运行 git merge 时所处的分支,而第二个父 commit 是被合并的分支。
git stash pop 恢复改动。如果你要恢复的是最近的一次改动,git stash pop即可,我用这个用的最多。...此时,合并merge是必须的。 ? 如果想更改一次提交,使用 git commit --amend。git会使用与当前提交相同的父节点进行一次新提交,旧的提交会被取消。...比如,git checkout HEAD~ foo.c会将提交节点HEAD~(即当前提交节点的父节点)中的foo.c复制到工作目录并且加到暂存区域中。...如果另一个分支是当前提交的祖父节点,那么合并命令将什么也不做。 另一种情况是如果当前提交是另一个分支的祖父节点,就导致fast-forward合并(指向只是简单的移动,并生成一个新的提交)。 ?...否则就是一次真正的合并。默认把当前提交(ed489 如下所示)和另一个提交(33104)以及他们的共同祖父节点(b325c)进行一次三方合并。
时被保存的内容 如果我对某文件进行了修改,但我不想要push到远程仓库,同时我又想获取最新的修改记录 git stash save git pull --rebase 如果暂存内容现在不想在当前分支恢复了...1、如果你已经push到远程仓库,reset删除指定commit以后,你git push可能导致一大堆冲突.但是revert 并不会 2、如果现有分支和历史分支需要合并的时候,reset 恢复部分的代码依然会出现在历史分支里...,必须commit之后,才能切换 如果要不计后果的情况,强切,加-f 将当前的分支修改的内容同步到其他的分支上 假如你希望变更作用于另一个分支上,但由于当前分支如果不提交,是无法切换到另一个分支上的...git checkout -m [另一个分支名] 将一个区间的提交,移植到另一个分支 #当前分支,得到dev分支中dev~2之前的所有提交内容 git cherry-pick dev~2 cherry-pick...ASCII 图形表示的分支合并历史 –pretty 使用其他格式显示历史提交信息。
dfb02e6e4f2f7b573337763e5c0013802e392818 增加v1.0的tag到某个提交上 git merge testBranch 合并testBranch分支至当前分支`...1.1 merge 合并 merge 合并两个分支时会产生一个特殊的提交记录,它有两个父节点。简单说就是:“我要把这两个父节点本身及它们所有的祖先都包含进来。”...如果想完全恢复本地分支到远程的状态,可以执行 git reset--hard origin/bugFix,或者你可以 git reflog 找到对应提交记录回滚,但是有点麻烦 1.4 rebase需要谨慎使用...如果此回退的分支合并主干分支时,reset 恢复部分的代码依然会出现在历史分支里,但是revert 方向提交的commit 并不会出现在历史分支里。...延伸用法 移动分支可以直接使用 -f 选项让分支指向另一个提交。例如下面的命令会将 master 分支强制指向 HEAD 的第 3 级父提交。
如果想更改一次提交,使用 git commit --amend。git会使用与当前提交相同的父节点进行一次新提交,旧的提交会被取消。 ? 另一个例子是分离HEAD提交,后文讲。...比如,git checkout HEAD~ foo.c会将提交节点HEAD~(即当前提交节点的父节点)中的foo.c复制到工作目录并且加到暂存区域中。...如果另一个分支是当前提交的祖父节点,那么合并命令将什么也不做。另一种情况是如果当前提交是另一个分支的祖父节点,就导致fast-forward合并。指向只是简单的移动,并生成一个新的提交。 ?...否则就是一次真正的合并。默认把当前提交(ed489 如下所示)和另一个提交(33104)以及他们的共同祖父节点(b325c)进行一次三方合并。...Rebase 衍合是合并命令的另一种选择。合并把两个父分支合并进行一次提交,提交历史不是线性的。衍合在当前分支上重演另一个分支的历史,提交历史是线性的。
不过需要特别留意的是这些改动没有提交到 Git 仓库,Git 无法追踪其历史,一旦回滚就直接丢弃了。...如果要回滚的是一个合并 commit,revert 时要加上"-m 父节点序号>",指定回滚后以哪个父节点的记录作为主线。...合并的 commit 一般有 2 个父节点,按 1、2 数字排序,对于要回滚“分支合入主干的 commit”,常用"-m 1",即用主干记录作为主线。...Reflog - 恢复到特定 commit 一个典型场景是执行 reset 进行回滚,之后发现回滚错了,要恢复到另一个 commit 的状态。...文件还是需要的,于是将该文件版本单独恢复到工作区中。
相对引用 HEAD^ 上1级; HEAD^^ 上2级; HEAD^2 当HEAD有2个父节点的时候,HEAD^回到第一个父节点,也就是HEAD正上方的节点,HEAD^2回到第2个父节点; HEAD...checkout的用法 1.从暂存区恢复到工作区 1 $ git checkout -- readme.txt(文件名) 工作区修改还未add到暂存区,可以从暂存区覆盖到工作区,即撤销修改 加上占位符...1 $ git checkout (版本号) 使Head指向指定的版本,并且整个工作区被该版本覆盖,此时分支处于未命名状态,可以用当前状态创建一个新分支,或者切回到另一个已存在分支。...在主分支基础上有C1,C2,C3,C4,C5 5个提交,除了C5是最后结果,前面的提交都是开发中的过程产生的冗余提交,不需要合并到主分支。...rebase -i master #以master作为源,同时使用-i参数选择dev分支的C5作为要合并的提交版本(不加-i会使用dev分支的全部提交版本)$ git checkout master
tag v1.0 dfb02e6e4f2f7b573337763e5c0013802e392818 增加 v1.0 的 tag 到某个提交上 • git merge testBranch 合并 testBranch...我们之前整合分支用的最多的就是 merge 了,那 merge 和 rebase有什么区别呢? 1. merge merge 合并两个分支时会产生一个特殊的提交记录,它有两个父节点。...如果想完全恢复本地分支到远程的状态,可以执行 git reset --hard origin/bugFix ,或者你可以 git reflog 找到对应提交记录回滚,但是有点麻烦。...• 如果此回退的分支合并主干分支时,reset 恢复部分的代码依然会出现在历史分支里,但是 revert 方向提交的 commit 并不会出现在历史分支里。...延伸用法: 移动分支:可以直接使用 -f 选项让分支指向另一个提交。例如下面的命令会将 master 分支强制指向 HEAD 的第 3 级父提交。
如果想更改一次提交,使用git commit --amend。git会使用与当前提交相同的父节点进行一次新提交,旧的提交会被取消。 ? 另一个例子是分离HEAD提交,后文讲。...如果另一个分支是当前提交的祖父节点,那么合并命令将什么也不做。 另一种情况是如果当前提交是另一个分支的祖父节点,就导致fast-forward合并。指向只是简单的移动,并生成一个新的提交。 ?...否则就是一次真正的合并。默认把当前提交(ed489 如下所示)和另一个提交(33104)以及他们的共同祖父节点(b325c)进行一次三方合并。...Rebase 衍合是合并命令的另一种选择。合并把两个父分支合并进行一次提交,提交历史不是线性的。衍合在当前分支上重演另一个分支的历史,提交历史是线性的。...树对应着工作目录中的文件夹,树中包含的 树或者blob对象对应着相应的子目录和文件。每次提交都存储下它的上一级树的识别码。
如果想更改一次提交,使用 git commit —amend。git 会使用与当前提交相同的父节点进行一次新提交,旧的提交会被取消。 另一个例子是分离 HEAD 提交,后文讲。...Reset reset 命令把当前分支指向另一个位置,并且有选择的变动工作目录和索引。也用来在从历史仓库中复制文件到索引,而不动工作目录。 如果不给选项,那么当前分支指向到那个提交。...如果另一个分支是当前提交的祖父节点,那么合并命令将什么也不做。另一种情况是如果当前提交是另一个分支的祖父节点,就导致fast-forward合并。指向只是简单的移动,并生成一个新的提交。...否则就是一次真正的合并。默认把当前提交(ed489 如下所示)和另一个提交(33104)以及他们的共同祖父节点(b325c)进行一次三方合并。...Rebase 衍合是合并命令的另一种选择。合并把两个父分支合并进行一次提交,提交历史不是线性的。衍合在当前分支上重演另一个分支的历史,提交历史是线性的。
比如,git checkout HEAD~ foo.c 会将提交节点 HEAD(即当前提交节点的父节点)中的 foo.c 复制到工作目录并且加到暂存区域中。...如果另一个分支是当前提交的祖父节点,那么合并命令将什么也不做。另一种情况是如果当前提交是另一个分支的祖父节点,就导致 fast-forward 合并。指向只是简单的移动,并生成一个新的提交。 ?...否则就是一次真正的合并。默认把当前提交(ed489 如下所示)和另一个提交(33104)以及他们的共同祖父节点(b325c)进行一次三方合并。...Rebase rebase 是合并命令的另一种选择。合并把两个父分支合并进行一次提交,提交历史不是线性的。rebase 在当前分支上重演另一个分支的历史,提交历史是线性的。...在此之前,我已经分享过两篇 Git 方面的文章了,都很受欢迎,如果没看到的话,可以回顾一下: 牛逼的 Git 保姆级 Git 入门教程,万字详解 毋庸置疑,Git 是目前最流行、最好用的版本控制系统,在它的基础之上
1. merge ★merge 合并两个分支时会产生一个特殊的提交记录,它有两个父节点。简单说就是:“我要把这两个父节点本身及它们所有的祖先都包含进来。”...然后 git rebase --edit-todo 可以继续vi编辑 fixup 合并commit到前面而且commit,commit msg也没了 drop 删除某个commit 注意:如果想要恢复这一次...如果想完全恢复本地分支到远程的状态,可以执行 git reset --hard origin/bugFix ,或者你可以 git reflog 找到对应提交记录回滚,但是有点麻烦 4. rebase需要谨慎使用...如果此回退的分支合并主干分支时,reset 恢复部分的代码依然会出现在历史分支里,但是revert 方向提交的commit 并不会出现在历史分支里。...延伸用法:移动分支可以直接使用 -f 选项让分支指向另一个提交。例如下面的命令会将 master 分支强制指向 HEAD 的第 3 级父提交。
如果想更改一次提交,使用git commit –amend。Git会使用与当前提交相同的父节点进行一次新提交,旧的提交会被取消。 另一个例子是分离HEAD提交[3],后文讲。...如果另一个分支是当前提交的祖父节点,那么合并命令将什么也不做。另一种情况是如果当前提交是另一个分支的祖父节点,就导致fast-forward合并。指向只是简单的移动,并生成一个新的提交。...否则就是一次真正的合并。默认把当前提交(ed489 如下所示)和另一个提交(33104)以及他们的共同祖父节点(b325c)进行一次三方合并[4]。...Rebase 衍合是合并命令的另一种选择。合并把两个父分支合并进行一次提交,提交历史不是线性的。衍合在当前分支上重演另一个分支的历史,提交历史是线性的。...树对应着工作目录中的文件夹,树中包含的 树或者blob对象对应着相应的子目录和文件。每次提交都存储下它的上一级树的识别码。
如果想更改一次提交,使用 git commit --amend。git会使用与当前提交相同的父节点进行一次新提交,旧的提交会被取消。 另一个例子是分离HEAD提交,后文讲。...如果另一个分支是当前提交的祖父节点,那么合并命令将什么也不做。另一种情况是如果当前提交是另一个分支的祖父节点,就导致fast-forward合并。指向只是简单的移动,并生成一个新的提交。...否则就是一次真正的合并。默认把当前提交(ed489 如下所示)和另一个提交(33104)以及他们的共同祖父节点(b325c)进行一次三方合并。...Rebase 衍合是合并命令的另一种选择。合并把两个父分支合并进行一次提交,提交历史不是线性的。衍合在当前分支上重演另一个分支的历史,提交历史是线性的。...树对应着工作目录中的文件夹,树中包含的 树或者blob对象对应着相应的子目录和文件。每次提交都存储下它的上一级树的识别码。
如果想更改一次提交,使用git commit –amend。Git会使用与当前提交相同的父节点进行一次新提交,旧的提交会被取消。 另一个例子是分离HEAD提交[3],后文讲。...比如,git checkout HEAD~ foo.c会将提交节点HEAD~(即当前提交节点的父节点)中的foo.c复制到工作目录并且加到暂存区域中。...如果另一个分支是当前提交的祖父节点,那么合并命令将什么也不做。另一种情况是如果当前提交是另一个分支的祖父节点,就导致fast-forward合并。指向只是简单的移动,并生成一个新的提交。...否则就是一次真正的合并。默认把当前提交(ed489 如下所示)和另一个提交(33104)以及他们的共同祖父节点(b325c)进行一次三方合并[4]。...Rebase 衍合是合并命令的另一种选择。合并把两个父分支合并进行一次提交,提交历史不是线性的。衍合在当前分支上重演另一个分支的历史,提交历史是线性的。
如果想更改一次提交,使用git commit –amend。Git会使用与当前提交相同的父节点进行一次新提交,旧的提交会被取消。 ? 另一个例子是分离HEAD提交[3],后文讲。...比如,git checkout HEAD~ foo.c会将提交节点HEAD~(即当前提交节点的父节点)中的foo.c复制到工作目录并且加到暂存区域中。...如果另一个分支是当前提交的祖父节点,那么合并命令将什么也不做。另一种情况是如果当前提交是另一个分支的祖父节点,就导致fast-forward合并。指向只是简单的移动,并生成一个新的提交。 ?...否则就是一次真正的合并。默认把当前提交(ed489 如下所示)和另一个提交(33104)以及他们的共同祖父节点(b325c)进行一次三方合并[4]。...Rebase 衍合是合并命令的另一种选择。合并把两个父分支合并进行一次提交,提交历史不是线性的。衍合在当前分支上重演另一个分支的历史,提交历史是线性的。
此选项指定主线的父编号(从 1 开始),并允许恢复相对于指定父级的更改。 还原合并提交声明您永远不会希望合并带来的树更改。因此,以后的合并只会带来由不是先前还原的合并的祖先的提交引入的树更改。...此标志应用将命名提交还原到工作树和索引所需的更改,但不进行提交。此外,使用此选项时,索引不必与 HEAD 提交匹配。恢复是针对索引的开始状态完成的。...当提交移动或复制一行行(例如原始文件有 A 然后是 B,并且提交将其更改为 B 然后 A)时,传统的 _ 指责 _ 算法仅注意到一半的移动和通常会将向上移动(即 B)的行归咎于父级,并将责任归咎于向下移动...更一般地说,一个对象可以从另一个到达,如果我们可以通过链跟随标签到达另一个到它们标记的任何东西,将提交给他们的父母或树木,将树提交给他们所包含的树木或 blob 。...虽然 ^ 是关于指定单个提交父级,这三个符号也考虑其父级。例如你可以说 HEAD ^ 2 ^ @ ,但你不能说 HEAD ^ @ ^ 2 。
领取专属 10元无门槛券
手把手带您无忧上云