Фиксация машины определенные конфигурационные файлы

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

Сначала я создаю новую ветку на основе главной ветки (в этом конкретном случае я использую git-svn, поэтому мне нужно зафиксировать from master, но здесь это не очень важно):

git checkout -b work master

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

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

#!/bin/sh

BRANCH=`git branch | grep ^\\* | cut -d' ' -f2`
if [ $BRANCH != "master" ]; then
  echo "$0: Current branch is not master"
  exit 1
fi

git log --pretty=oneline work...master | grep -v NOCOMMIT: | cut -d' ' -f1 | tac | xargs -l git cherry-pick

Сначала проверяется, что я нахожусь на ветке master (проверка работоспособности). Затем он перечисляет каждую фиксацию в работе , отфильтровывает те, которые упоминают ключевое слово NOCOMMIT, меняет порядок и, наконец, отбирает каждую фиксацию (теперь начиная с самой старой) в master ].

Наконец, после внесения изменений в основной восходящий поток, я переключаюсь обратно на work и перебазирую:

git checkout work
git rebase master

Git повторно применяет каждый из коммитов в ветке work , фактически пропуская по сравнению с теми, которые уже были применены в master через выборку вишен. У вас должны остаться только локальные коммиты NOCOMMIT.

Одна из возможностей - иметь актуальные файлы в вашем .gitignore, но проверять конфигурации по умолчанию с другим расширением. Типичным примером приложения Rails может служить файл config / database.yml. Мы проверяем config / database.yml.sample, и каждый разработчик создает свой собственный config / database.yml, который уже имеет .gitignored.

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

Кроме того, напишите сценарий быстрой установки, который устанавливает символические ссылки для всего вашего приложения.

Мы использовали аналогичный подход в предыдущей компании. Сценарий установки автоматически определил, в какой среде вы работали (песочница, разработка, контроль качества, производство), и автоматически поступил правильно. Если у вас есть файл config.sandbox, и вы запускаете его из песочницы, он будет связывать его (в противном случае он просто связывает файл .defaults). Обычная процедура заключалась в копировании .defaults и изменении настроек по мере необходимости.