В моем Git-репозитории у меня есть файл, который должен содержать местоположение моего рабочего каталога.Это будет отличаться для каждого человека, который клонирует репозиторий, и важно, чтобы этот конкретный файл имел правильный (уникальный) каталог для каждого пользователя.Большая часть содержимого файла является общей для всех пользователей, за исключением уникального пути к файлу.
Обратите внимание, что мы не можем поддерживать другой файл (уникальное имя файла или местоположение файла в Git) для пользователя, посколькучто наши инструменты ищут это конкретное местоположение и имя файла.
В настоящее время мы работаем с этим путем обновления пути к файлу, чтобы он указывал на наш рабочий каталог, а затем мы никогда не фиксируем это обновление.Мы оставляем это как локальное изменение, и когда мы извлекаем или объединяем ветки, мы храним это локальное изменение, чтобы избежать любых конфликтов.Когда вытягивание / слияние завершено, мы открываем тайник.Вот пример рабочего процесса, в котором мы фиксируем локальные изменения в одной ветви (например, ветви функций), а затем объединяем их с другой веткой (такой как master).Мы помещаем все изменения в обе ветви и используем git stash и git stash pop, чтобы скрыть локальные изменения во время этого процесса.
// starting in branch named "original_branch"
git commit // our other changes that we do want to share with others
git stash // stash the one file with the updated user directory
git pull
git push
git checkout another_branch
git pull
git merge original_branch
git push
git stash pop
Для меня это лишь незначительная неприятность, потому что рабочий процесс работает вышепросто хорошо.Но поскольку я работаю с командой, подобные обходные пути в конечном итоге приводят к ошибкам, и тогда мне нужно тратить время на то, чтобы помочь людям разрешать конфликты и другие проблемы с Git, а не выполнять свою реальную работу.Было бы идеально, если бы я мог как-то сделать так, чтобы каждый пользователь фиксировал свою версию файла с обновленным путем к файлу в своем локальном репозитории без того, чтобы это изменение передавалось в удаленный репозиторий, когда они отправляли другие изменения.Это кажется невозможным, но я надеюсь, что кто-то знает о решении здесь.
Вот как я представляю, что решение будет выглядеть так:
vim special_file.txt // update just that one line in special_file.txt
git commit --local-only -- special_file.txt
git commit -- some_other_file.txt
git push // only pushes the update for some_other_file.txt
Конечно, я только что составил опцию --local-only для git commit, но я надеюсь, что кто-то знает о чем-то подобном.Я проверил Google и переполнение стека, но никто, похоже, не задавал подобный вопрос.
РЕДАКТИРОВАТЬ: До сих пор большинство выдвинутых предложений былисвязанные с решениями, которые не основаны на Git (например, символические ссылки).Первоначально я хотел решение на основе Git, как я описал выше, потому что оно решило бы мою проблему, а также учел ряд других ограничений, которые я еще не упомянул.Позвольте мне перечислить здесь другие ограничения, чтобы их можно было принять во внимание, когда мы пытаемся найти решение.
- Инструмент не принадлежит мне или моей команде, поэтому мы можем 't изменить его поведение.
- Каждый клон Git должен соответствовать уникальному каталогу.То есть это не может быть общий клон, который используется несколькими пользователями.
- Все пользователи используют одну и ту же файловую систему, поэтому использование фиксированного каталога нарушит ограничение (2).
- Каждый идентификатор пользователя может соответствовать нескольким клонам Git, поэтому мы не можем настроить наш клон как каталог (или символическую ссылку) с фиксированным именем в наших домашних каталогах, потому что это позволит только один клон Git на идентификатор пользователя.
- Инструмент не может развернуть переменные среды, чтобы получить путь к файлу.
- Путь к файлу должен быть в этом конкретном файле.Мы не можем включить другой файл, содержащий путь.
- Этот файл должен отслеживаться в Git, чтобы мы могли иметь контроль версий для содержимого файла (кроме одногострока, содержащая путь к файлу).
- Инструмент обращается к файлу по символической ссылке, которая существует за пределами рабочего каталога.Это означает, что мы не можем использовать относительный путь к файлу, потому что инструмент в конечном итоге будет искать путь относительно символической ссылки, а не искать путь относительно фактического файла в рабочем каталоге.
- Решение должно быть реализовано несколькими людьми, поэтому решение должно быть относительно простым, простым и безболезненным.Например, ожидать, что каждый человек создаст несколько идентификаторов пользователей и будет переключаться между ними, когда он хочет переключать задачи, было бы слишком сложно.
- В нашем репозитории Git есть много таких файлов, поэтому было бы идеально, если бы мыможет найти решение, которое не требует дополнительных человеческих усилий для каждого файла.