git 如何摆脱gerrit中的错误依赖
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10402285/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to get rid of false dependencies in gerrit
提问by Shellum
It appears that when using gerrit, by default all changes depend on the previous one. I do not branch for new changes, I simply work off the master branch and then push the commited changes to a remote origin/master. A dependency is created every time even if the two commits have nothing to do with each other.
似乎在使用 gerrit 时，默认情况下所有更改都依赖于前一个。我不为新的更改分支，我只是在主分支上工作，然后将提交的更改推送到远程源/主。即使两次提交彼此无关，每次都会创建一个依赖项。
I've run into a few issues which makes me think that I am not using git correctly in combination with gerrit.
我遇到了一些问题，这让我觉得我没有正确地将 git 与 gerrit 结合使用。
What should happen differently in my git/gerrit workflow for every commit to not be dependent on the previous commit? I've also tried creating a new branch for the change:
对于不依赖于先前提交的每次提交，在我的 git/gerrit 工作流程中应该发生什么不同的情况？我还尝试为更改创建一个新分支：
> git pull origin master
> git checkout -b new_branch
> #make a change
> git add -A
> git commit #with gerrit's commit hook in .git/hooks
> git push origin <sha1>:refs/for/master
This works, but gerrit still reports a dependency on the previously commited item.
这有效，但 gerrit 仍然报告对先前提交的项目的依赖。
回答by Brad
This is what Gerritmeans by dependencies - A commit which is on top of another commit. If both are in review, the newer one depends on the older one.
这就是Gerrit依赖关系的含义 - 在另一个提交之上的提交。如果两者都在审核中，则较新的取决于较旧的。
If you don't want them to depend on each other, don't create the commits on top of each other. Create one commit, then make a new branch based on master for your next commit
如果您不希望它们相互依赖，请不要在彼此之上创建提交。创建一个提交，然后为下一次提交基于 master 创建一个新分支
(git checkout origin/master -b NEW_BRANCH_NAME).
(git checkout origin/master -b NEW_BRANCH_NAME).
When you push the second commit up for review, it's parent will already be published and it won't depend on anything.
当您推送第二个提交以供审核时，它的父项将已经发布，并且不会依赖任何内容。
回答by Mitch
I've been taught to get around this by doing git reset --hard HEAD~1after each git push.
我被教导通过git reset --hard HEAD~1在每个git push.
回答by docwhat
As a variant to git reset --hard HEAD~1I use this instead:
作为git reset --hard HEAD~1我使用它的一个变体：
git reset --hard origin/master
Assuming, I'm working in masterfor a quick change.
假设，我正在努力master进行快速更改。
Otherwise, working in a topic branch is much preferred.
否则，更喜欢在主题分支中工作。
There are many Git scripts to help manage topic branches:
有很多 Git 脚本可以帮助管理主题分支：
git-flowgit extrasgit create-branch
git-flowgit extrasgit create-branch
I'm sure there are others.
我确定还有其他人。
