Как отследить локальные изменения / наборы изменений с помощью git-svn?

Question

Я хочу иметь файлы, которые я отслеживаю в своем локальном репозитории git, которые не регистрируются в центральном репозитории svn, когда я запускаю git-svn dcommit. У меня часто бывают долговременные локальные изменения файлов, отслеживаемых в хранилище. Иногда это для отладки кода. У меня также есть файлы IDE проекта, которые я бы хотел отслеживать. При использовании старого старого svn я просто поместил бы эти файлы в список изменений, помеченный «XYZ: НЕ ПРОВЕРИТЬ ВХОД», а затем просто вручную решил проблему, когда у меня действительно есть изменения, которые мне нужно зафиксировать.

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

Я рассмотрел и отбросил пару вещей. Я не хочу исключать эти файлы, потому что иногда мне нужно вносить изменения, которые действительно будут приняты. Кроме того, я хотел бы, чтобы эти файлы появлялись в любых локальных ветках, которые я создаю, как в случае файлов IDE. Однако я не могу изолировать эти изменения в одной ветви, потому что я хочу, чтобы они были в каждой ветви, как и в файлах IDE. Похоже, что-то вроде вины или stgit может делать то, что я хочу, но это не очевидно, поскольку они добавляют свой слой сложности поверх git, который я все еще изучаю.

Answer 1

Мое текущее решение проблемы состоит в том, чтобы использовать git (stg) в стеке и поддерживать эти локальные изменения как отдельные исправления. Когда мне нужно войти в Subversion, я делаю

stg pop # naming the patches that should not be commited
stg commit # the rest of the patches to commit
git svn dcommit
stg push # naming the patches that are used locally

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

stg push local-mods-derby
ant tests
stg pop

или, если я хочу протестировать PostgreSQL, я запускаю

stg push local-mods-test-postgresql
ant tests
stg pop

Здесь "local-mods-derby" и "local-mods-test-postgresql" являются именами патчей.

Так что поддерживать отдельные патчи работы очень просто с помощью stg.

Answer 2

Я немного новичок в git, но я бы порекомендовал использовать отдельный мастер и рабочую ветку в вашем локальном репозитории git.

Добавьте ваши файлы "не-SVN" только в рабочую ветку. В общем случае вносите все изменения кода в рабочую ветку. Когда файлы «не-SVN» изменятся, добавьте те, которые используют уникальный коммит, и установите префикс сообщения фиксации (то есть «local:» или «private:»). Когда вы будете готовы совершить коммит в SVN, тогда:

1. Показать журнал коммитов для добавления в SVN:

   git co working
   git cherry master
   

2. Добавить все восходящие коммиты в основную ветку, игнорируя "приватные" коммиты. Повторяйте этот шаг, пока все вышестоящие коммиты не будут в мастере.

   git co master
   git cherry-pick <SHA1>
   

3. Push-коммиты в репозитории SVN:

   git svn rebase
   git svn dcommit
   

Answer 3

Считаете ли вы, что не работаете в основной ветке?

Если вы храните свои изменения в локальной ветке Git, вы можете периодически объединять или выбирать только нужные изменения в вашей ветке отслеживания SVN. Переключитесь на ветку трекинга, запустите ваш dcommit. Затем вернитесь в местное отделение и перебазируйте его.

Если вы хотите изменения в нескольких ветвях, основывайте их на одной точке ветвления. Сохраните эту ветвь как master + изменения путем перебазирования. Затем для всех остальных веток просто перебазируйте эту базовую ветку.

Answer 4

Я провел небольшое исследование и нашел возможность, которая могла бы это сделать: 2 репозитория git, указывающих на один и тот же каталог. Переменная среды GIT_DIR хранит имя каталога локального хранилища. Если не установлено, git по умолчанию имеет значение .git, но это может быть что угодно.

Тогда я мог бы иметь один репозиторий в .git, который отображается на мой репозиторий Subversion. Это частый случай. Тогда я мог бы иметь другой репозиторий в .localgit. Каждый репозиторий должен быть настроен так, чтобы игнорировать файлы, управляемые другим. Это легко с! для отрицания шаблонов.

Когда я изменяю локальные файлы, которые я хочу зарегистрировать, я либо изменяю переменную среды GIT_DIR, либо использую аргумент командной строки --git-dir. Если я правильно настрою исключения / игнорирование, мне не придется беспокоиться о столкновениях. Очевидно, есть некоторые накладные расходы, чтобы поддерживать это в актуальном состоянии, но я могу написать скрипт-обертку, который добавляет файл к исключению одного репо, когда файл добавляется к другому. Кроме того, эти издержки происходят только один раз для каждого файла, а не для каждого коммита, как с предложением с несколькими ветвями.

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

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

Answer 5

Возможно, вы захотите использовать тайник для этого.

git-stash - Stash the changes in a dirty working directory away

Это может быть недостаточно для того, что вы описываете.