Может ли git игнорировать определенную строку?

Если ваш файл относится к определенному типу, вы можете объявить драйвер фильтра содержимого, который можно объявить в .gitattributes файле ( как представлено в расширении ключевых слов Атрибуты Git ):

*.yourType filter=yourFilterName

(вы даже можете установить этот фильтр для определенного файла, если хотите)

Воплощать в жизнь:

• yourFilterName.smudge (сработало git checkout) и

    git config --global filter.yourFilterName.smudge 'sed "s/isPhoneGap = .*/isPhoneGap = true/"'
  

• yourFilterName.clean (сработало git add)

    git config --global filter.yourFilterName.clean 'sed "s/isPhoneGap = .*/isPhoneGap = false/"'
  

Ваш файл будет отображаться без изменений git status, но его извлеченная версия будет иметь правильное значение для isPhoneGap.

Примечание: в комментариях, ohaal и Роальд предлагают чтобы изолировать sed вызовы в отдельном helper.sh скрипте:

sed "s/isPhoneGap = .*/isPhoneGap = true/" "$@"

Ты можешь использовать

git update-index --assume-unchanged [file]

игнорировать изменения одного файла, которые вы не хотите отслеживать. Я использую это решение, когда мне нужно иметь файл в репозитории, но в этом файле есть некоторые части, которые меняются, и мне не нужно постоянно отслеживать.

Когда в файле есть важные изменения, вам необходимо сделать следующее:

git update-index --no-assume-unchanged [file]

Также см. Git doc update-index для параметра --[no-]assume-unchanged.

Когда эти флаги указаны, имена объектов, записанные для путей, не обновляются. Вместо этого эти параметры устанавливают и сбрасывают бит «считать неизменным» для путей. Когда бит «предполагать неизменность» включен, git перестает проверять файлы рабочего дерева на предмет возможных модификаций, поэтому вам нужно вручную сбросить бит, чтобы сообщить git, когда вы изменяете файл рабочего дерева.

Gitx должен позволять вам фиксировать или игнорировать отдельные строки (вы, возможно, уже знаете об этом), но вам придется делать это каждый раз, когда вы фиксируете. Я думаю, что было бы лучше иметь файл конфигурации для каждой цели развертывания (вы можете версия для них) и некоторый параметр времени выполнения, независимо от того, запускаете ли вы сервер (например, ./myserver --config=whatever.js).

Продолжая https://stackoverflow.com/a/20574486/4935114, @ Mike предложил создать pre-commit ловушку, которая grep будет в промежуточных файлах для строк, которые можно игнорировать. Хук проверяет, были ли эти строки поставлены. Если да, то это echo предупреждение и exit код 1, поэтому процесс фиксации не будет продолжен.

Вдохновленный ответом Майка, я обнаружил, что использую, возможно, улучшенную версию его крючка, который автоматически resets (с флагом -p) конкретная строка, которую мы хотим игнорировать.

Я не уверен, что этот хук будет работать в ситуации, когда у вас есть много файлов с этой строкой, которые нужно игнорировать, но этот pre-commit хук ищет изменения в этой строке в конкретном файле buildVars.java. Скрипт перехвата выглядел так, когда я тестировал его на своей машине.

#!/bin/sh

# this hook looks for lines with the text `var isPhoneGap = false;` in the file `buildVars.java` and it resets these lines to the previous state before staged with `reset -p`

if [[ $(git diff --no-ext-diff --cached buildVars.java | grep --count -e "var\ isPhoneGap[\ ]*=[\ ]*") -ne 0 ]]; then
    cat <<EOW
WARNING: You are attempting to commit changes which are not supposed to be commited according to this \`pre-commit\` hook
This \`pre-commit\` hook will reset all the files containing this line to it's previous state in the last commit.
EOW
    echo /$'\n'isPhoneGap$'\n'y$'\n'q | git reset -p
    # BONUS: Check if after reseting, there is no actual changes to be commited and if so, exit 1 so the commit process will abort.
    if [[ $(git diff --no-ext-diff --cached | wc -l) -eq 0 ]]; then
        echo there are no actual changes to be commited and besides the change to the variable \'isPhoneGap\' so I won\'t commit.
        exit 1
    fi
fi

Объяснение

Я повторил контрольные последовательности, которые ищут регулярное выражение isPhoneGap во время интерактивного reset процесса. Таким образом, имитируя пользователя, который нажимает / для поиска isPhoneGap, нажимает y, когда его спрашивают, хочет ли он отменить этот патч, и наконец нажимает q для выхода из интерактивного reset.

Интерактивный обратный процесс исправления документирован здесь: https://git-scm.com/docs/git-add#git-add-patch.

ПРИМЕЧАНИЕ. В приведенном выше сценарии предполагается, что переменная interactive.singleKey - это false. Если вы настроили свой на true, удалите любой $'\n' из команды echo сразу после предупреждения.

Вот как это можно сделать с помощью фильтров git < / а>:

Драйвер фильтра содержимого - не лучшее решение. Вы можете скрыть эту строку из git status / etc, но на самом деле она не игнорируется. Как только вы измените значение, ваш рабочий каталог будет помечен как грязный, даже если изменение может быть не видно.

Если вы действительно хотите, чтобы эта строка вышла из-под контроля версий, изменение ее на аргумент командной строки или помещение ее в игнорируемый файл include или build может быть единственным практическим средством.

Я предполагаю, что это может быть что-то, что встречается более чем в одной строке вашего источника.

Я думаю, что было бы лучше всего иметь какой-то файл .userbuildconfig, который вы просто включаете и проверяете значения по умолчанию. Затем вы можете использовать Предложение Карлоса пометить только этот файл как предполагаемый без изменений. Таким образом не будут пропущены другие изменения в файле, в котором нужно проверить настройку.

Это может позволить вам настраивать макросы препроцессора локально (или для java что-то вроде этого https://stackoverflow.com/a/1813873/1270965 < / а>).

Неа. Вы можете игнорировать только отдельные файлы (и многое другое), поскольку строки в .gitignore соответствуют именам файлов, а не содержимому файла. Вы уже упомянули решение этой проблемы, то есть игнорируйте один файл, содержащий тот контент, который вы хотите игнорировать.

Я думаю, что никто не предоставил такой способ решения проблемы, так что вот мой метод. Я веду журнал / отладку и т. Д. В одной ревизии (на самом деле, их может быть несколько) в частной ветке в моем локальном репо. Итак, когда я запускаю функциональную ветку и хочу иметь все свои плюшки (в ветке my-goodies), я просто делаю следующее:

git checkout my-feature
git cherry-pick my-feature..my-goodies # assuming both started from the same main branch, say, my-goodies started a few (or many) revisions back

Теперь я начинаю работать над этой функцией. Когда я закончу, я переписываю историю ветки функций, чтобы эти изменения исчезли:

git rebase -i @{u} # set all the goodies revisions to skip, save, and go

Теперь моя ветка чиста от всех моих вкусностей, и я могу пихать куда угодно.