Как убрать файл конфигурации Tomcat из-под контроля версий [дубликат]

#java #git #tomcat

        
             
                
                    
                        
                            На этот вопрос уже даны ответы здесь:
                            
                        
                    
                
                        
                            git и конфигурационные файлы
                                
                                    (7 ответов)
                                
                        
                                Закрыт 2 года назад.
            
                    
Склонировал проект, там есть файл (назовем его файл1) конфигурации который мне нужно
поправить под себя.

Это приложение на Java Spring, предлагается использовать Tomcat и править $TOMCAT_HOME/conf/Catalina/localhost/*.xml,
но я запускаю с idea через tomcat + артефакт.

Файл уже отслеживается, я добавил его в .git/info/exclude и теперь он числится как
deleted. Закоммитил изменения в свой репо, возможно уже тут я начал совершать ошибку.

Сделал отдельную ветку в которой буду делать работу, сделал изменения (назовем их
файл2) нужных мне файлов, закоммитил и отправил ветку на гитхаб. Захожу на гитхабе
в ветку с изменениями, жму pull request и вижу там на отправу файл1 и файл2.

Как мне в pull request отправлять только файл2?
    

Ответы

Ответ 1

Как мне в pull request отправлять только файл2


Разово решить проблему, восстановив файл

В пулл-реквест предлагаются не файлы, туда предлагается некоторая ветка (а по сути
— коммит, на который эта ветка указывает). В вашей ветке этот файл конфигурации поменялся
по сравнению с оригинальной — придётся откатить это изменение. Как-то так:

# копируем свой конфиг куда-нибудь рядом
cp foobar.conf foobar.conf.bak

# достаём версию конфига из стабильной ветки
git checkout origin/master -- foobar.conf

# добавляем в индекс и коммитим
git add foobar.conf
git commit -m'restore configuration'

# отправляем изменения в ветку, обновляя пулл-реквест
git push

# возвращаем свой рабочий конфиг
rm foobar.conf
mv foobar.conf.bak  foobar.conf


Оставить файл, но перестать фиксировать будущие изменения (не выйдет)

Для того, чтобы вовсе убрать этот файл из-под контроля версий, придётся сделать две вещи:


Добавить его в .gitignore или ./git/info/exclude
Сообщить git об удалении файла: git rm --cached foobar.conf.


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

Решить проблему в корне

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

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

По моему опыту, хорошо работает такая модель:


Репозиторий не содержит сами конфигурационные файлы. Вместо них:


Либо образцы файлов типа foobar.conf.example. Вы копируете их и получаете foobar.conf.
Либо инструмент для генерации файлов — это может быть отдельный скрипт (какой-нибудь
configure.sh или configure.bat), параметр запуска приложения, система сборки (maven,
 ant...) или система управления конфигурациями (Ansible, Saltstack, Puppet, Chef). 

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