git rebase - 我的哈希的意外不匹配 [英] git rebase -- unexpected mismatch of my hashes

问题描述

1）为什么我没有机会展示我的提交片断，因此我可以在与团队合并之前将它们逗逗进行不同的提交？
2）为什么rebase之前的哈希值不等于rebase之后的哈希值？

  GIT [工作] git log --oneline -n​​10 $ b我没有看到表明有压扁的空白或其他东西的消息。 $ b 7784ea8 dataloader为masteritem和event填充相对健全的数据;一些组件更改
 1d9b3fe masterlist，提升草稿，各种命令，显示所有组件的调整
 76bea59显示字符串
 ... 
 GIT [工作] git rebase -i团队
  

编辑第一个提交，压扁下两个提交

 停在76bea59 ...显示字符串
您可以使用
 
 git commit --amend 
 
来修改提交一旦你对你的修改感到满意，运行
 
 git rebase --continue 
 
 PS [55] git status 
＃目前没有任何分支。 
没有提交（工作目录干净）
 PS [56] git rebase --continue 
 [detached HEAD e373567]显示字符串
更改49个文件，917个插入（+）， 460删除（ - ）
删除模式100644源/ ... 
删除模式100644源/ ... 
删除模式100644源/ ... 
 ... 
成功改版并更新参考资料/主管/工作。 
 GIT [工作] git log --oneline -n​​10 
 e373567显示字符串
 bddc2fe对象attrs的单元测试，验证在框架中重复
 548e1e9与cvs同步;固定测试用例编译错误
  

解决方案

我所说的是，我的OP中的rebase的净结果没有变化，所以即使rebase（根据定义） t保留提交历史记录，只是发生旧头的sha1散列和新头的sha1散列应该是相同的，尽管它们是单独的提交，因为它们的文本内容完全相同。

提交的哈希取决于：

1. 这个提交的树（即你的源代码的当前状态）
   
2. 任何提交父母的散列
   
3. 提交元数据（作者日期，作者，提交日期，提交者，提交信息和类似信息。）

重新绑定后，第一个是相同的，我不确定）甚至是最后一个（至少是其中的一部分）。但第二个肯定是不一样的，因此你会得到另一个提交ID。这是一件好事，因为它允许您同时拥有存储库中的原始和新提交。

1) why wasn't i given an opportunity to stage pieces of my commits so i can tease them into distinct commits before merging with team? 2) why doesn't the hash before the rebase equal to the hash after the rebase? I see no messages indicating there was a squashed whitespace or something.

GIT [work]  git log --oneline -n10
7784ea8 dataloader populates with relatively sane data for masteritem and event; some component changes
1d9b3fe masterlist, promote draft, various commands, display tweaks on all components
76bea59 display strings
...
GIT [work]  git rebase -i team

edit first commit, squash next two commits

Stopped at 76bea59... display strings
You can amend the commit now, with

        git commit --amend

Once you are satisfied with your changes, run

        git rebase --continue

PS [55] git status
# Not currently on any branch.
nothing to commit (working directory clean)
PS [56] git rebase --continue
[detached HEAD e373567] display strings
 49 files changed, 917 insertions(+), 460 deletions(-)
 delete mode 100644 source/...
 delete mode 100644 source/...
 delete mode 100644 source/...
 ...
Successfully rebased and updated refs/heads/work.
GIT [work]  git log --oneline -n10
e373567 display strings
bddc2fe unit test for object attrs, verify repeating in framework
548e1e9 sync with cvs; fixed test case compile error

解决方案

You wrote in a comment:

what im saying is that the net result of the rebase in my OP was no change, so even though rebase (by definition) doesn't preserve commit history, it just so happens that the sha1 hash of the old head and the sha1 hash of the new head would be expected to be identical, despite being separate commits, because their text content is exactly the same

The hash of a commit is depending on:

1. the tree of this commit (i.e. the current state of your sources)
2. The hashes of any parents of the commit
3. the commit metadata (author date, author, commit date, committer, commit message, and similar.)

After your rebase the first one is the same, and maybe (I'm not sure) even the last one (at least, parts of it). But certainly the second one is not the same, and thus you get another commit-ID. This is a good thing, as it allows you to have at the same time the original and the new commit in your repository.

这篇关于git rebase - 我的哈希的意外不匹配的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！