1

Моя команда использует sourcetree в качестве нашего git-клиента. В нашем проекте есть сторонний плагин. Требуется несколько файлов конфигурации. Эти файлы не могут быть созданы автоматически. Они хранят имя учетной записи, токены входа в систему и некоторые временные параметры, которые не должны быть разделены. Но этот файл все еще нужен, иначе он сообщит об ошибке. Так что теперь они всегда остаются в нашем разделе "незафиксированные изменения", что раздражает.

У меня есть 2 варианта:

  1. Удалите эти файлы из репозитория git. Добавьте их в .gitignore. Попросите всех членов моей команды добавить эти файлы обратно в их локальный проект со своими настройками.

  2. Посмотрите, есть ли такие хитрости, как "игнорирование отслеживаемого файла без его удаления".

(По сути, я чувствую, что если вариант 2 возможен, в git должна быть логика типа «Если у local нет этого файла, используйте удаленную версию». Если у local есть этот файл, игнорируйте ". Логика чувствует себя плохо, легко генерировать ошибки.)

|источник

2 ответа2

1

ТЛ; др

  • Технически ваше требование противоречиво.

  • На более философском уровне это (кажется) столкновение между открытым исходным кодом и корпоративной философией.

  • Во всяком случае ... я предложу некоторые вещи, которые приходят мне в голову

технически

git либо отслеживает, либо игнорирует файл.

  • Отслеживание легче (есть). Просто ничего не делайте ... кроме использования мерзавца! И любой файл отслеживается.
  • Игнорировать это почти так же просто - просто убедитесь, что оно соответствует чему-то в вашем файле gitignore.
  • Но вы не можете сделать оба!
  • Основная оговорка: перемещение файла из отслеживаемого в игнорируемое несколько нетривиально - простое добавление подходящего шаблона в gitignore не обрезает его после отслеживания. Подходящий

Лучшая практика

Не запускайте git-проект без создания правильного

  • gitignore
    Также связано
  • gitattributes

Итак, первое (и несколько нереальное)

Предложение 1

  • Начать новый проект git
  • Сделайте правильные файлы gitignore и gitattribute
  • Отладка при необходимости с помощью git-check-ignore
  • Скопируйте, добавьте, зафиксируйте ваши обычные файлы
  • Скопируйте, добавьте, состояние файлов, которые не будут отслеживаться. Статус должен быть чистым

Но, как я сказал, это, кажется, не совсем то, что вы хотите, потому что вам нужны какие-то общие, но не отслеживаемые файлы. Так что вам нужно

Отследить отслеженные файлы

Вы на самом деле хотите мерзавца

Пост-клон крюк

Это попытка здесь

Но это плохая идея, как объясняется здесь

Что подводит меня к

Философская разница

  • Корпоративный работодатель обоснованно хочет контролировать, что / как функционируют его сотрудники-программисты. Что влечет за собой различные виды управления машиной
  • Случайное программное обеспечение с открытым исходным кодом, расположенное на github, которое берет на себя управление машиной другого случайного человека, является неэтичным и незаконным.

Поэтому, если бы вы были большим игроком с Fortune-500, естественным вариантом было бы раскошелиться на самого git и добавить функцию пост-клонового хука в ваш форк.

Более разумный и только немного более неудобный

Решение 2

  • Напишите свой собственный пост-клон, но вручную вызываемый скрипт
  • ... что делает требование копии, если отсутствует, оставить в покое, если присутствует
  • И добавьте (ручной) шаг в вашу команду: (1) clone (2) скрипт вызова
  • И не забывайте, Gitignore!

Если это решение имеет смысл, вы можете предпочесть

Решение 3

Инвертировать скрипт-внутри-мерзавца в сценарий-мерзавца

то есть попросите вашу команду только скачать / скопировать и запустить скрипт, который

  • Запускает git clone
  • Проверяет наличие / пригодность этих других файлов
  • Создает / загружает их при необходимости (возможно, из источника, независимого от вашего основного репо)
|источник
0
  1. Удалите эти файлы из репозитория git. Добавьте их в .gitignore. Попросите всех членов моей команды добавить эти файлы обратно в их локальный проект со своими настройками.

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

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

  • Параметры, специфичные для сайтов / разработчиков, не вызывают проблем безопасности, связанных с информацией об аутентификации, но они по-прежнему будут вызывать проблемы, если задействованы несколько сайтов или разработчиков, потому что, даже если у вас есть политика против принятия / отправки изменений в эти файлы, это Это всего лишь вопрос времени, когда кто-то фиксирует их и вызывает изменение настроек всех остальных (или создание ложных конфликтов) при следующем запуске. У меня есть личный опыт с этим, и с этим постоянно приходится сталкиваться. В нашем случае некоторые различия были связаны с настройками разработки и производства, а также с настройками, специфичными для конкретной площадки, и это вызывало неоднократные негативные последствия для наших производственных систем.

Один хакерский обходной путь, который я видел в нескольких проектах, - это создать очищенную копию foo.cfg именем foo.cfg.default , отследить foo.cfg.default в git, gitignore foo.cfg и рассчитать , что пользователь скопирует foo.cfg.default для foo.cfg после клонирования и настройки его (добавление учетных данных для аутентификации, персонализированных настроек и т. д.). В вашем случае, поскольку файлы конфигурации предназначены для стороннего плагина, это может сработать, поскольку они, вероятно, довольно стабильны. Это менее эффективно в сценариях, где foo.cfg.default будет часто меняться, так как тогда пользователь должен будет заметить любые изменения и вручную объединить их в локальный foo.cfg .

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .