__pycache__ 合并冲突未由 gitignore 解决

Question

我正在尝试将开发分支合并回主分支。我已经在这两个文件中运行git rm '*.pyc'，这是我的 gitignore （从这里复制）：

# Byte-compiled / optimized / DLL files

__pycache__/

*.py[cod]

*$py.class

# C extensions

*.so

# Distribution / packaging

.Python

build/

develop-eggs/

dist/

downloads/

eggs/

.eggs/

lib/

lib64/

parts/

sdist/

var/

wheels/

share/python-wheels/

*.egg-info/

.installed.cfg

*.egg

MANIFEST

# 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 logs

pip-log.txt

pip-delete-this-directory.txt

# Unit test / coverage reports

htmlcov/

.tox/

.nox/

.coverage

.coverage.*

.cache

nosetests.xml

coverage.xml

*.cover

*.py,cover

.hypothesis/

.pytest_cache/

cover/

# Translations

*.mo

*.pot

# Django stuff:

*.log

local_settings.py

db.sqlite3

db.sqlite3-journal

# Flask stuff:

instance/

.webassets-cache

# Scrapy stuff:

.scrapy

# Sphinx documentation

docs/_build/

# PyBuilder

.pybuilder/

target/

# Jupyter Notebook

.ipynb_checkpoints

# IPython

profile_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 stuff

celerybeat-schedule

celerybeat.pid

# SageMath parsed files

*.sage.py

# Environments

.env

.venv

env/

venv/

ENV/

env.bak/

venv.bak/

# Spyder project settings

.spyderproject

.spyproject

# Rope project settings

.ropeproject

# mkdocs documentation

/site

# mypy

.mypy_cache/

.dmypy.json

dmypy.json

# Pyre type checker

.pyre/

# pytype static type analyzer

.pytype/

# Cython debug symbols

cython_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.pycdeleted in version3ascii and renamed tovenv/lib/python3.7/site-packages/astroid/brain/brain_subprocess 3.pyin 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.（可能其他选项之一比“核武器铺路”更有用，即使您确实选择“核武器铺路”（删除并重新创建），您也可能不想像这样批量进行这。）