Я ищу в Интернете, как использовать git pull без изменения конкретных файлов, но я хожу по кругу и теряюсь.
Это сценарий, у меня есть несколько файлов конфигурации, скажем, один из них называется C, и в этом файле по некоторым причинам есть мой локальный путь, находящийся в том же файле, но на машинах моих коллег у него есть пути к файлам . Итак, C содержит столько же разных состояний, сколько и общее количество коллег в нашей рабочей группе.
Чтобы использовать C локально на каждой из наших машин, мы выполнили git update-index --assume-unchanged ..path-to-C../C, так что всякий раз, когда один из нас делает push, этот конкретный файл не принимается во внимание. Другими словами, если я правильно понял, C не будет обновляться в репозитории на git, даже если мы внесем в него локальные изменения. Таким образом, каждый из нас может указать свой путь к файлу.
Но это только половина проблемы.
Теперь я хочу сказать git, что я не хочу, чтобы вы каким-либо образом изменяли мой локальный C, пока я делаю тягу.
Как мне получить такой результат?
Я не хочу использовать .gitignore, потому что в ходе проведенных нами тестов мы увидели некоторые поведения, которых не хотим. Например, если мой коллега помещает C в .gitignore и делает push, когда я выполняю pull, мой C не будет присутствовать в моем локальном репо. Поэтому каждый раз, когда я делаю тягу, мне придется C вручную внутри своего проекта, чтобы он заработал.
Это связано с тем, что для его работы мы выполняем следующую комбинацию команд:
git rm --cached ..path-to-C../C
move C to the .gitignore (with intellij .ignore plugin)
from intellij mark it as a file to be untracked
В результате Intellij выделяет наш файл желтым цветом, чтобы сказать, что этот файл официально не отслеживается.
Я хочу автоматизировать эту часть процесса, пометив каким-то образом файл, как я сделал для push, но в данном случае для pull.
stackoverflow.com/a/1733921/341994 — person config.err schedule 12.11.2020
Вы можете использовать тайник как обходной путь и создать псевдонимы командной строки, которые используют этот обходной путь. Затем используйте эти псевдонимы вместо обычных pull / push — person config.err schedule 12.11.2020
Обратите внимание: если файл C существует в коммитах и в индексе Git (который заполняется в из коммитов), перечисление файла C в .gitignore буквально не имеет никакого эффекта. Так что упоминание .gitignore здесь неуместно. Что действительно важно, так это этот трюк. — person config.err schedule 13.11.2020
Важно то, что незафиксированные изменения в файле C будут мешать слияниям, которые действительно имеют изменения в файле C. Помните, что git pull означает запустить git fetch, а затем запустить вторую команду Git. Вторая команда Git по умолчанию git merge. Вы можете изменить выбор второй команды, но другой вариант — git rebase — здесь не поможет. Проблема в самом файле C. Не делай так. — person config.err schedule 13.11.2020
Если вы … э-э … обязались (если вы извините за выбор слова) в любом случае сделать это таким образом, что ж, теперь вы должны разобраться с проблемой. Это почти все, что нужно сделать. — person config.err schedule 13.11.2020
@torek извините, torek Я не очень хорошо объяснил процесс, который следует за подходом .gitignore, теперь я отредактировал вопрос, надеюсь, процесс станет более понятным — person config.err schedule 13.11.2020