Предотвращение удаления игнорируемых файлов во время извлечения

Мы используем Git в нашей организации для обновления кода на серверах для всех проектов. Часто разработчики забывают игнорировать файлы, которые следует игнорировать (например, конфигурацию базы данных или данные и т. д.), и помещают их на наш сервер Git. Который позже синхронизируется с фактическим сервером, на котором выполняется код (с помощью хуков). git pull выполняется на сервере для получения последнего кода.

Теперь, если я добавлю какой-либо конкретный файл в .gitignore и удалю его из index и push на сервер, используя приведенные ниже команды.

git rm --cached config.php
git add .gitignore
git commit -m "removed config file and ignored it"
git push origin master

Это удалит файл из Git, но не из моего локального репозитория. Это также предотвратит дальнейшее отслеживание.

Затем на сервере выполняется git pull, который удаляет недавно проигнорированный файл, вызывающий проблемы. Простая команда pull выполняется на сервере, как показано ниже:

git pull origin master

Я не хочу удалять файл config.php с сервера при удалении его из удаленного репозитория git.

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

Что было бы самым простым и программируемым решением для этого? Я разработал программу Node.js, которая входит на сервер и программно запускает там команду pull.


person shashwat    schedule 28.08.2015    source источник
comment
stackoverflow.com/a/31289998/6309 может помочь   -  person VonC    schedule 28.08.2015


Ответы (1)


Вы не можете; вы записываете удаление, и удаление происходит, когда вы выполняете обновление. На самом деле это то, что вы хотели бы сделать, если бы вы зафиксировали файл, который вам не нужен; вы не ожидаете, что он останется висеть после этого.

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

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

Как вы обучаете своих пользователей - это отдельный вопрос...

person AlBlue    schedule 28.08.2015
comment
Ты прав. Я понимаю, как это работает, и это нормально. Разве раздавливание фиксации не перепишет историю? Я не позволяю разработчикам делать принудительный толчок, чтобы предотвратить перезапись чужой работы. - person shashwat; 28.08.2015
comment
Вы должны заставить разработчиков сделать сквош на их собственной локальной машине перед загрузкой. Если вы напишете хук фиксации, они не смогут повредить центральный репозиторий. Затем они могут перебазировать свои на последнюю версию, чтобы не повредить историю общего репозитория. - person AlBlue; 28.08.2015
comment
Вы сказали write a commit hook on the server, но в большинстве случаев первая фиксация делается из локальной системы разработчиков. А затем он клонируется на сервер с нашего Git-сервера. - person shashwat; 28.08.2015
comment
Хорошо, но у нас есть 100 проектов. Невозможно создать обработчики коммитов (относящиеся к проектам) для каждого проекта в системе разработчика до того, как разработчик выполнит push. - person shashwat; 28.08.2015
comment
Есть ли способ настроить некоторые шаблоны файлов глобально (для всех проектов) на сервере Git, чтобы он не получал коммиты, которые добавляют/изменяют файлы, соответствующие любому из этих шаблонов? Мой сервер Gitlab CE. - person shashwat; 28.08.2015
comment
@shashwat Подойдет ли вам размещение config.php в подмодуле? Таким образом, он и в источнике, и в локальном, но вы никогда не забудете добавить его, потому что он находится в подмодуле, который отслеживается отдельно. Назвать его config.git тоже будет неплохо. Вы даже можете создать один подмодуль config для всех имеющихся у вас репозиториев и управлять этими файлами в древовидной структуре, организованной «для каждого проекта». С другой стороны - разработчики забудут запустить git submodule update. Может, разработчикам не стоит забывать? :) - person Zloj; 13.10.2015