1 Вопрос: Исключить некоторые отслеживаемые файлы из постоянной фиксации

вопрос создан в Thu, May 2, 2019 12:00 AM

Я работаю над проектом, в котором я отредактировал некоторые файлы, которые были отслежены Git . Допустим, отредактированные отслеживаемые файлы:

files1.py
file2.py
file3.py

Все эти файлы существуют в удаленном хранилище. Однако я отредактировал один из файлов (например, file2.py), чтобы он был совместим только с моей машиной. Поэтому при фиксации я не хочу, чтобы этот файл был зафиксирован (я хочу, чтобы удаленная версия этого файла была неизменной).
Я знаю, что для этого есть команды:
по этой ссылке

git add
git reset --file2.py

Или по этой ссылке :
git update-index --assume-unchanged "file2.py"

Тем не менее, я хочу, чтобы этот файл игнорировался при каждой последующей фиксации без выполнения указанных выше команд.
Существует ли способ, аналогичный .gitignore, чтобы этот файл автоматически игнорировался при фиксации каждый раз и всегда оставлял удаленную версию без изменений?

    
1
  1. Нет. git update-index это единственный способ. Лучший способ - вообще не фиксировать локальные файлы: stackoverflow.com/search?q=%5Bgit% 5D + приложения + конфигурация
    2019-05-02 15: 16: 40Z
  2. @ phd, спасибо за комментарий. Как изменить указанный файл с отслеженного на локальный?
    2019-05-02 15: 19: 28Z
  3. git rm --cached file2.py но, пожалуйста, поймите, что после того, как вы нажмете на изменение, все, кто извлекает данные из этого хранилища, получат удаленный файл. Даже если вы извлечете другую ветку и вернетесь назад, файл будет удален.
    2019-05-02 15: 25: 06Z
  4. Спасибо за объяснение, я думаю, что лучшее и самое безопасное решение - использовать git update-index
    2019-05-02 15: 27: 28Z
1 ответ                              1                         

Вы можете делать все, что хотите, используя ловушку предварительной фиксации :

  

перед фиксацией
  Этот хук вызывается git-commit и может быть обойден с помощью опции --no-verify. Он не принимает параметров и вызывается до получения предложенного сообщения журнала фиксации и создания коммита. Выход из этого сценария с ненулевым состоянием приводит к прерыванию команды git commit до создания коммита.

Простой код, приведенный ниже, обрабатывает любые изменения в file2.py непосредственно перед фиксацией и отказывается создавать любую новую пустую фиксацию, то есть, если единственным измененным файлом был file2.py.

#! /bin/bash

if ! git diff-index --quiet --cached HEAD -- file2.py; then
  echo Discarding file2.py changes from the index
  git reset HEAD -- file2.py

  if git diff-index --quiet --cached HEAD; then
    echo Aborting empty commit 1>&2
    exit 1
  fi
fi

Теперь, когда на академический вопрос получен ответ, я предлагаю использовать другой подход, поскольку ловушка намеренно отбрасывает усилия по управлению версиями двух разных разновидностей file2.py обратно на пользователя. Если вы хотите осуществлять контроль версий вручную, зачем вообще использовать git?

Вместо этого позвольте git выполнять свою работу, поместив ваши изменения в отдельную ветку

git checkout --no-track -b feature/singrium origin/master

это как главное изменение (к которому вы прибегаете, запустив git fetch)

git checkout feature/singrium
git rebase origin/master

или в который вы периодически сливаете изменения из основного.

git checkout feature/singrium
git merge origin/master

Разница между git rebase и git merge заключается в их соответствующих историях. Если ваши изменения в file2.py невелики и локализованы для небольшого числа коммитов, то при подходе rebase эти коммиты объединяются в виде патча поверх того, чем является последний мастер. Если ваша история более громоздкая, слияния могут быть проще, по крайней мере, в краткосрочной перспективе.

    
1
2019-05-02 18: 51: 04Z
  1. Спасибо за объяснение!
    2019-05-03 10: 36: 19Z
источник размещен Вот