__pycache__ 合并冲突未由 gitignore 解决

Question

我正在尝试将开发分支合并回主分支。我已经在这两个文件中运行git rm '*.pyc'，这是我的 gitignore （从这里复制）：# Byte-compiled / optimized / DLL files__pycache__/*.py[cod]*$py.class# C extensions*.so# Distribution / packaging.Pythonbuild/develop-eggs/dist/downloads/eggs/.eggs/lib/lib64/parts/sdist/var/wheels/share/python-wheels/*.egg-info/.installed.cfg*.eggMANIFEST# PyInstaller#  Usually these files are written by a python script from a template#  before PyInstaller builds the exe, so as to inject date/other infos into it.*.manifest*.spec# Installer logspip-log.txtpip-delete-this-directory.txt# Unit test / coverage reportshtmlcov/.tox/.nox/.coverage.coverage.*.cachenosetests.xmlcoverage.xml*.cover*.py,cover.hypothesis/.pytest_cache/cover/# Translations*.mo*.pot# Django stuff:*.loglocal_settings.pydb.sqlite3db.sqlite3-journal# Flask stuff:instance/.webassets-cache# Scrapy stuff:.scrapy# Sphinx documentationdocs/_build/# PyBuilder.pybuilder/target/# Jupyter Notebook.ipynb_checkpoints# IPythonprofile_default/ipython_config.py# pyenv#   For a library or package, you might want to ignore these files since the code is#   intended to run in multiple environments; otherwise, check them in:# .python-version# pipenv#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.#   However, in case of collaboration, if having platform-specific dependencies or dependencies#   having no cross-platform support, pipenv may install dependencies that don't work, or not#   install all needed dependencies.#Pipfile.lock# PEP 582; used by e.g. github.com/David-OConnor/pyflow__pypackages__/# Celery stuffcelerybeat-schedulecelerybeat.pid# SageMath parsed files*.sage.py# Environments.env.venvenv/venv/ENV/env.bak/venv.bak/# Spyder project settings.spyderproject.spyproject# Rope project settings.ropeproject# mkdocs documentation/site# mypy.mypy_cache/.dmypy.jsondmypy.json# Pyre type checker.pyre/# pytype static type analyzer.pytype/# Cython debug symbolscython_debug/

Answer 1

首先，请注意，.gitignore内容本身永远不会对合并产生任何直接影响。这是因为合并了commitsgit merge的内容，这些内容已经提交并且无法更改。他们拥有他们拥有的文件。地球上或其他任何地方的任何力量都无法改变它们。您正在合并一些现有的提交，准备进行新的提交。git merge

我已经git rm '*.pyc'在这两个文件中运行过...

您的意思是“在两次提交中”吗？“在两个文件中”在这里没有什么意义。

我不记得重命名或删除任何venv/lib/*文件。

如果venv/lib包含*.pyc文件，并且您运行了上面的命令，您将从工作树和 Git 索引中git rm删除这些文件。*.pyc一旦文件脱离 Git 的索引，现有*.pyc条目中的现有条目.gitignore就会生效，从而防止未来的*.pyc文件通过工作树进入 Git 的索引。随后的提交将缺少这些*.pyc文件。

我将在这里查看第一个冲突，并仅出于发布目的而分开长行：

CONFLICT (rename/delete):

venv/lib/python3.7/site-packages/

astroid/brain/__pycache__/brain_subprocess.cpython-37 2.pyc

deleted in version3ascii and renamed to

venv/lib/python3.7/site-packages/

astroid/brain/brain_subprocess 3.py

in HEAD. ...

这一切真正意味着：

• 合并基础提交包含一个名为 的文件.../__pycache__/brain_subprocess.cpython-37 2.pyc；

• 提交version3ascii缺少该文件；和

• 该HEAD版本也缺少此文件，但有一个名为.../astroid/brain/brain_subprocess 3.py

并且HEAD该新名称的内容与旧名称下的合并基础内容相似，足以决定在git merge合并基础提交和提交之间进行更改的人HEAD必须重命名（并且可能还修改）了合并基础副本文件。

合并基础提交似乎更有可能具有这些*.pyc文件和所有这些venv/*文件，并且这些*.pyc文件在两个分支提示提交（version3ascii分支提示和当前分支提示）中都被正确删除。但是，某些venv/*文件存在于 中HEAD，但可能不存在version3ascii（否则 Git 可能会在那里检测到类似的重命名）。.py该文件似乎也不是该文件的重命名和修改后的副本.pyc，Git 的相似性检测器只是将其误检测为重命名。

前进的道路有很多。例如：

• 如果venv/*任何一个分支提示提交中都不应该有任何文件，您可以只进行两个缺少这些文件的新分支提示提交。现在，Git 不会找到看起来相似的文件来声称重命名，这会让 Git 相信不真实的事情。

• 如果您不想进行新的提交，则可以中止此合并并使用扩展参数（-X参数）重新运行，该扩展参数将重命名阈值设置得更高或完全关闭重命名检测器，例如git merge -Xfind-renames=99将其限制为 99%相似的文件，而不是 50% 相似的文件。

• 或者，您可以简单地手动调整 Git 索引中的所有内容。事实是，合并因合并冲突而停止。现在您的工作就是安排获得正确的合并结果。这些不需要与三个输入提交中的任何一个匹配，尽管正确的合并可能以某种方式使用所有三个输入。由于git merge 已完全停止，您现在可以完全控制最终运行git merge --continue或git commit完成合并时索引中的内容。您可以运行git rm -r .以删除几乎所有内容，从整个布构建所有新文件，并且git add.

（可能其他选项之一比“核武器铺路”更有用，即使您确实选择“核武器铺路”（删除并重新创建），您也可能不想像这样批量进行这。）