#git #github
Вопрос:
У меня есть несколько файлов конфигурации для запуска IDE, которые я хотел бы сохранить в своем репозитории git, чтобы наша команда могла поделиться ими. К сожалению, позже они могут быть изменены, чтобы включить свойства частной или защищенной системы. Поэтому я также хотел бы запретить им меняться после совершения. Первоначально сохраненные файлы не будут содержать никакой частной, безопасной или конфиденциальной информации.
Можно ли навсегда зафиксировать файлы в хранилище и навсегда запретить их изменение? Я знаю о временных способах сделать это на локальном клоне (например, отследить файл), но я хотел бы всегда иметь их в удаленном, просто проинструктируйте git никогда не отслеживать никаких изменений, даже для новых клонов.
Комментарии:
1. Личные и защищенные данные вообще не принадлежат Git.
2. Если файл отслеживается, то не регистрировать изменения в этом файле, которые необходимо не регистрировать, зависит от конкретного пользователя. Вы не можете волшебным образом навязать это сверху; люди должны использовать свои мозги.
3. @chepner Отсюда и вопрос
4. Разделите свою конфигурацию на два набора файлов. Один для значений по умолчанию, один для локальных переопределений. Зафиксируйте файлы по умолчанию. Добавьте локальные файлы переопределения в файл .gitignore. Запретите вносить изменения в файл по умолчанию во время процесса проверки или используйте крючок Git .
5. @Schwern Да, это имело бы смысл, и если бы IDE поддерживала это, я бы так и сделал. Если git не может это поддержать, тогда все в порядке, и я что-нибудь придумаю. Но мне просто интересно, не упустил ли я что-то из возможностей git. Пока что похоже, что нет.
Ответ №1:
Можно ли навсегда зафиксировать файлы в хранилище и навсегда запретить их изменение?
Как бы.
Вот несколько вариантов, которые «как бы» достигают того, чего вы хотите:
- Настройте крюк фиксации, который разработчики используют локально, чтобы предотвратить случайную фиксацию этого файла.
- Настройте правило владельца кода в GitHub для этого конкретного файла в сочетании с защитой от ветвей, чтобы только определенные пользователи могли разрешить выполнение PR в случае изменения этого файла.
Вы не можете заставить № 1. Вы можете заставить #2, но это не помешает разработчикам случайно вставить конфиденциальные данные в общее хранилище. Но это, по крайней мере, предотвратило бы его слияние без одобрения определенных людей. Возможно, какая-то комбинация из них была бы лучшей.
Альтернатива?
Другой подход состоял бы в том, чтобы попытаться полностью избежать этого. Один из способов добиться этого-создать файл наложения/преобразования, который не отслеживается и может находиться в файле .gitignore. Тогда вы можете иметь:
my-file-base # checked in and tracked like a normal file
my-file-override # Listed in .gitignore
И «вещь», которая читает этот файл, может проверить наличие my-file-override , и если она там есть, она может изменить my-file-base с помощью переопределений и/или добавить новые материалы. Каждый разработчик может настроить это по своему желанию.
Примечание сбоку:
Просто одно предостережение из документации Git относительно update-index :
Пользователи часто пытаются использовать биты предполагаемого неизмененного и пропущенного рабочего дерева, чтобы указать Git игнорировать изменения в отслеживаемых файлах. Это работает не так, как ожидалось, так как Git все еще может проверять файлы рабочего дерева на соответствие индексу при выполнении определенных операций. Как правило, Git не предоставляет возможности игнорировать изменения в отслеживаемых файлах, поэтому рекомендуется использовать альтернативные решения.
Комментарии:
1. Спасибо! Все это допустимые варианты, и я не рассматривал #2 и #3.
2. @ScottShipp #2-это крючок Git на стороне клиента, а #3-это что-то вроде крючка Git на стороне сервера на уровне PR, но вы находитесь во власти того, что GitHub позволяет вам делать на своих серверах, чего, к счастью, здесь, вероятно, достаточно.
3. В часто задаваемых вопросах Git специально указано, что не следует использовать
git update-indexдля этой цели, и объясняется, что вы должны делать вместо этого.4. @bk2204 Thx за то, что указал на это. Я убрал эту опцию. Альтернатива, которую предлагает Git, — это именно то, что я предложил. 😉
Ответ №2:
Часто задаваемые вопросы Git охватывают случай, когда требуется игнорировать изменения в отслеживаемых файлах, и объясняют, почему это невозможно с помощью Git.
К счастью, легко справиться с конфигурационным случаем, с которым вы хотите справиться. Возьмите фактический файл конфигурации и проигнорируйте его. Затем проверьте шаблон или набор значений по умолчанию, которые можно настроить самостоятельно или использовать сценарий для настройки, скопировав в фактическое расположение файла конфигурации. Это рекомендуемый подход для большинства из этих случаев.
Если вы используете корпоративный сервер GitHub, вы можете ограничить передачу определенных файлов с помощью крючка предварительного приема, но эта возможность недоступна на github.com. Независимо от этого, лучше избежать необходимости в крючке, если это возможно, используя рекомендуемый подход.