Fatal编程技术网
  • git/
  • Git 这两种移动分支的方式有区别吗？

Git 这两种移动分支的方式有区别吗？

git

Git 这两种移动分支的方式有区别吗？,git,git-branch,Git,Git Branch,我在学习交互式教程时，遇到了两种绕着树枝移动的方法。我想确保我没有遗漏任何东西 以下两者之间是否有区别： git branch -f master master^ 并且，假设HEAD指向master git reset HEAD^ 而且，如果他们做同样的事情，为什么要使用reset命令呢？这是否意味着它只是git branch-f的缩写 谢谢你 如genisage在中所述，git reset有多种模式 忽略所有模式及其作用，第一个问题的答案是：如果HEAD引用master，并且您使用gi

我在学习交互式教程时，遇到了两种绕着树枝移动的方法。我想确保我没有遗漏任何东西

以下两者之间是否有区别：

 git branch -f master master^
并且，假设
HEAD
指向
master

git reset HEAD^
而且，如果他们做同样的事情，为什么要使用
reset
命令呢？这是否意味着它只是git branch-f的缩写

谢谢你

如genisage在中所述，
git reset
有多种模式

忽略所有模式及其作用，第一个问题的答案是：如果
HEAD
引用
master
，并且您使用
git分支将
master
移动到另一个commit，那么是的，这实现了与使用
git reset
间接移动
master
相同的效果。但是：


  • 我们不能简单地忽略重置
    的选项
    • 

  • 我们还以“if
    HEAD
    指
    master
    ”开始回答。如果没有呢
    • 
特别是，对于第1点，
    git reset
    的默认模式是
    --mixed
    。
    reset
    命令不仅可以移动分支尖端，而且在这种情况下也可以。它还可以更新git的索引（也称为“暂存区”）
    
您可以而且实际上可能应该将git的索引/暂存区域想象为“下次运行
    git commit
    时git准备提交的内容”。当您
    git添加一个文件以使git为下一次提交获取更改时，git读取该文件的当前工作树版本，然后将其1写入索引
    

    git reset
    所做的（或可以做的，以及使用
    --mixed
    所做的）是撤销这种索引修改，方法是更改索引内容以匹配重置到的提交。也就是说，
    git reset--mixed HEAD^
    不仅将分支备份一次提交，还将所有索引内容重置为备份一次提交。
    git分支
    命令不触及索引
    
通过使用
    --soft
    选项，可以使
    git重置
    不接触索引。在这种情况下，它确实做了与您的
    git分支-f
    相同的事情，尽管如第2点所述，这仅在
    HEAD
    引用
    master
    时有效。如果要在不使用
    git reset
    的情况下执行软重置，第一步是找出
    HEAD
    指向哪个分支（如果有）。只有这样，您才能更新分支（并且只有在您未处于“分离头部”模式时）
    
为了完整起见，这里值得注意的是，
    git reset--hard
    比
    git reset--mixed
    做得更多：它不仅更新分支提示并重置索引，还“重置”工作树，使其看起来像新的目标提交
    
另外值得一提的是，
    git reset
    的几种常见用法故意只使用了它的一些操作：
    

      

    • git reset--soft HEAD^
      在不更改索引或工作树的情况下备份一次提交，因此新的
      git提交
      提供了一个新的分支提示，其内容与刚才备份的提交相同。这允许您更改提交消息。2这与git commit--amend完全相同，只是后者实际上更容易；因此，这种用法已不再常见（这是人们在使用
      git commit
      之前使用
      --amend
      选项时所做的）
      • 

    • git reset--mixed--
      将您“移动”到当前提交，也就是说，它重写当前分支以指向它已经指向的位置，这是一个no-op，但会重置索引，而不会更改工作树。这允许您“撤消”一个
      git add
      或
      git rm--cached
      .3通常拼写为
      git reset
      ，因为
      --mixed
      是默认值
      • 

    • git reset--hard
      或
      git reset--hard
      再次“移动”您根本不移动，而是重置索引并恢复工作树版本
      • 

    

    reset
    命令有几个额外的选项（
    --merge
    和
    --keep
    ；还有
    -p
    ）不太适合此模式。不过，为了避免这个答案太长，我将忽略它们
    

    
1实际上，git将文件（或“blob”）写入存储库，而不是索引。在编写blob的过程中，git还计算得到的SHA-1：对象的“真实名称”。（所有存储库对象都通过其“真实名称”SHA-1找到。存储库充当一个简单的键值存储，键值为SHA-1，值为对象：文件aka“blob”，或树，或提交，或带注释的标记对象。）SHA-1与文件名和执行权限位一起进入索引。随后，根据需要，在提交时将索引转换为一个或多个git“树”对象；这些树对象包含各种文件名、modse/execute权限和SHA-1
    
2更准确地说，您使用更正的消息进行新的、不同的提交。这也是git提交--amend所做的。旧的（修订前）提交仍在存储库中，具有相同的SHA-1；新提交具有不同的消息和时间戳，具有不同的SHA-1，即使它从相同的索引开始，因此附加了相同的树
    

    3A常规（非
    --cached
    ）
    git rm
    已从工作树中删除该文件，因此
    git reset--mixed
    不起作用
    git重置--hard
    就可以了，或者您可以
    git签出头--
    来取回文件。后者“写入”索引，因此它们在命令方面也是非常冗余的，比如
    git reset--soft
    vs
    git branch-f
    我不确定这两个函数是否在