GIT игнорирует локальные изменения в зафиксированном файле по умолчанию - PullRequest
0 голосов
/ 07 декабря 2018

У меня есть фиксированный файл "build.properties", этот файл должен быть в нашем репозитории проекта , поскольку он содержит важную информацию о сборке.

Иногда какой-то разработчик выполняет локальное тестированиеизмените содержимое этого файла, а затем они по ошибке фиксируют изменения (просто ставят все внесенные изменения, включая build.properties).

Теперь я хотел бы как-нибудь, чтобы игнорировать все локальные изменения, внесенные в этот файл, чтобы избежать этой ситуации, которая продолжает тормозить сборку, например, когда разработчик запустит * git add ** или git commit -a ,этот файл не будет включен в промежуточный файл.

Я уже провел некоторое исследование, но до сих пор не могу найти какое-либо решение, совместимое с тем, что я ищу, учитывая, что операцию нужно применять удаленно.Например, я могу использовать папку .git / info / exclude , но тогда каждый раз, когда новый разработчик будет клонировать репозиторий, он должен будет установить .git / info / exclude еще раз, и я бы хотел этого избежать.

Более того, .gitignore работает только с неотслеживаемым файлом, если я добавлю отслеживаемый файл в .gitignore, он вообще не будет игнорироваться.Я обнаружил, что некоторые люди предлагают использовать .gitignore в сочетании с git rm --cached, а затем повторно добавляют файлы, но как только файл повторно добавляется в дерево, изменения продолжают отслеживаться, также читая из официального документа GIT,.gitignore не подходит для моих нужд.

Есть решение?Спасибо!

ОБНОВЛЕНИЕ

Я большой поклонник SVN, и чем больше я знаю GIT, тем больше я ценю SubVersion.

Так что я думаюответ на мой вопрос: GIT не предоставляет никакого способа для достижения чего-то подобного ...

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

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

Ответы [ 2 ]

0 голосов
/ 07 декабря 2018

Я понимаю, что вы пытаетесь сделать, и причины этого обоснованы.Но дело в том, что это противоречит распределенной и параллельной природе Git.Git разработан как:

Система контроля версий для отслеживания изменений в компьютерных файлах и координации работы над этими файлами среди множества людей

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

Поэтому, учитывая, что Git не предназначен для того, чтобы делать то, что вы хотите, вы можете рассмотреть несколько вариантов:

  1. Все разработчики в вашей команде должны локально сообщить Git, что они не хотят вносить изменения в этот файл : это обходной путь.И цена этого - делать это каждый раз, когда вы клонируете репо.Если вы выберете это, вы можете рассмотреть возможность использования git update-index --skip-worktree <file> (вы можете узнать больше о том, почему использовать вместо других опций здесь );
  2. Извлечь расширения Git иузнайте, соответствует ли один из них вашим потребностям : я никогда не использовал его, но я знаю, что Git LFS поддерживает блокировку файлов.Он не был создан для того, что вы пытаетесь сделать, но это может быть вариант;
  3. Измените подход к решению проблем : Если вы используете Git и вам нужнаэто не устраивает его, вы можете либо бороться с Git, либо использовать его как есть и найти другой способ сделать то, что вы хотите.В конце концов, Git очень полезен для отслеживания вещей, и вы можете также захотеть изменить и зафиксировать свой файл в будущем.Как насчет того, чтобы придумать способ отделить ваши файлы свойств «по умолчанию» (те, которые были зафиксированы в репо) от ваших файлов свойств разработки (которые могут меняться в зависимости от потребностей каждого разработчика)?Я не знаком с вашей средой разработки, но я уверен, что вы можете найти способ использовать файл по умолчанию, если другой файл не был указан, и использовать конкретный файл, если он был указан.
0 голосов
/ 07 декабря 2018

Лучшим способом было бы иметь несколько build.properties для разных сред.

Пример: buildDev.properties для разработка среда, аналогично buildTest.properties и buildProd.properties для test и prod environment.

Примечание: git rm --cached используется, когда вы нажали файл для удаления, который вы не должны иметь, и теперьтакже хочу отследить это.В этом случае вы можете добавить имя файла в .gitignore, а затем использовать git rm --cached, чтобы удалить его из промежуточной области, а затем зафиксировать.Теперь эта фиксация удаляет файл, который можно отправить мастеру , не удаляя файл локально .

...