假设我有一个git repo,其工作树和/或索引是"脏的"(即我有尚未提交或隐藏的本地修改)并且我很想在没有先提交或存储的情况下执行"git pull".(或者,说我正在向git介绍一个新的团队成员,当他们的本地回购"肮脏" 时,他们很想运行"git pull ".)我想知道做一个"git pull"是多么安全这个案例.如果它不安全,那可能发生的最糟糕的事情是什么？如果我从受信任的vs不受信任的来源中撤出,这有关系吗？
到目前为止,我的调查表明,对于我所认为的一个相当简单的问题,一系列令人困惑的想法.
首先,git-stash手册页听起来像git pull非常安全,并且如果你遇到可能出错的情况,它会中止:
Pulling into a dirty tree
When you are in the middle of something, you learn that there are
upstream changes that are possibly relevant to what you are doing.
When your local changes do not conflict with the changes in the
upstream, a simple git pull will let you move forward.
However, there are cases in which your local changes do conflict
with the upstream changes, and git pull refuses to overwrite your
changes. In such a case, you can stash your changes away, perform a
pull, and then unstash, like this...
到目前为止,在我的简单测试中,这实际上似乎也是如此.
也许暗示"git pull"非常安全,Visual Studio 的Git Extensions工具栏有一个突出的拉动按钮,在敲出"git pull"之前不会检查肮脏.(如果我正在设计Visual Studio工具栏,我会尽量避免让自己在脚下射击特别容易.)
git-pull手册页并没有让我的"git pull"声音变得危险,尽管它表明这不是最佳做法:
If any of the remote changes overlap with local uncommitted changes,
the merge will be automatically cancelled and the work tree untouched.
It is generally best to get any local changes in working order before
pulling or stash them away with git-stash(1).
但是你也可以找到肮脏的建议非常糟糕,例如:
Avoid git-pull!
git-pull should never get invoked if you have dirty files lying around or if your branch is ahead of master.
This will always lead to some dirty artifacts in the commit history
对于哪种观点最好是否有一个简单的答案,或者这是某种情况下的具体情况？
跟帖:请问使用"混帐拉--rebase",而不仅仅是"混帐拉"改变的答案呢？在某些情况下,重新定位可能有其自身的 缺陷,但到目前为止,我的猜测是,使用脏工作树/索引不会使rebase比其他情况更有问题.
对于维护Apache DeltaSpike项目的人来说没有冒犯,但我相信Git手册中有关Git对Delta Spike wiki内容的评论.
另请注意在引用文本中(强调我的):
git-pull如果你周围有脏文件或者你的分支领先于master,那么永远不应该被调用.这将始终导致提交历史记录中的一些脏工件.
"提交历史中的脏工件"是Git合并提交.只要您合并分支而不是在另一个分支上重新定义一个分支的内容,就会发生这种情况.这些合并提交是否"脏"取决于您的项目,您的组织及其意见和政策.
无论如何,git-pull绝不是危险的操作.据记载,它不会破坏您的任何历史或正在进行的工作.