Работа в синхронизации с SVN, в восходящем направлении [закрытым]
4 ответа
Документация git svn рекомендует следующий рабочий процесс при работе с ветками Subversion:
# Clone a repo (like git clone): git svn clone http://svn.example.com/project -T trunk -b branches -t tags # Append svn:ignore settings to the default git exclude file: git svn show-ignore >> .git/info/exclude # View all branches and tags you have cloned: git branch -r # Create a new branch in SVN git svn branch waldo # Reset your master to waldo: git reset --hard remotes/waldo # local changes git add ... git commit ... # pull changes on current branch git svn rebase # send changes to Subversion git svn dcommit # check for new branches git svn fetch
Приведённый выше рабочий процесс предназначен для непрерывного изменения в одной ветке Subversion, к которой у вас есть роскошь в виде бита фиксации, но жонглирование несколькими активными ветками Subversion и git немного сложнее.
Чтобы отслеживать ветку waldo репозитория Subversion, начните с
git checkout -b waldo-svn remotes/waldo
Суффикс -svn нужен, чтобы избежать предупреждений вида
warning: refname 'waldo' is ambiguous.
а также чтобы напомнить вам, что эта ветка git предназначена для отслеживания ветки Subversion. Всегда сохраняйте изменения в этих ветках линейными!
Чтобы обновить waldo-svn, выполните
git svn rebase
Это приведет к получению изменений из Subversion и перебазированию всех локальных изменений поверх них. Он также достаточно умён, чтобы распознать, когда одно из ваших локальных изменений было принято дословно в Upstream: оно будет заменено коммитом Subversion и будет иметь строку, начинающуюся с git-svn-id: ... в сообщении о коммите.
Когда сопровождающие выше по течению изменяют содержимое и структуру ваших патчей (например, , изменяя код, разбивая патч на несколько коммитов Subversion или объединяя несколько патчей в один коммит), жизнь становится веселее, когда приходится разрешать конфликты и пытаться распутать путаницу.
Для полной общности, держите ваши ветки -svn в git чистыми (без изменений) и создавайте ветки выпусков от веток -svn. Чтобы отправить патч, используйте
git diff waldo-svn waldo-fix-frobnicator
Затем, когда вы git svn rebase догоните репозиторий Subversion, вам нужно будет просмотреть журнал и принять решение о соответствующем расположении ваших ветвей issue, своего рода GTD для git.
Я не уверен, насколько сильно ваши функции связаны с исходным кодом, но вы, возможно, могли бы разделить «ядро» восходящего потока, которое вы поддерживаете отдельно от ваших добавлений функций. Это действительно работает, только если вы можете разделить базу кода.
Я не совсем уверен, что понял вашу проблему, но думаю, что вы, возможно, ищете git stash .
Вы действительно не ясно дали понять, что хотите делать. Что касается вашего утверждения о том, что «(поэтому поддерживать отдельную ветку для каждой функции нетривиально)», я могу только задаться вопросом, почему вы думаете, что это должно быть тривиально. Два патча, которые взаимно зависят друг от друга, должны быть либо одним патчем, либо, по крайней мере, одной ветвью. Патч B, который зависит от A (но не наоборот), должен находиться либо в ветке с A, либо в ветке с родительским коммитом в ветке A.
Теперь, если вы хотите поддерживать «четкое представление» о том, где находятся ваши патчи вверх по течению, это сводится к сохранению локальной копии всех ветвей апстрима. Я не понимаю, где в этом проблема. Вам действительно нужно быть точным, если вы хотите получить более точный ответ.
Хорошо, теперь с этим легче справиться.
У вас две проблемы.
(1) получает коммиты вилки, которые никогда не переходят из основной ветки разработки в ветвь вилки, как только вы понимаете, что никогда не отправляете их обратно.
Сделайте ветку вилки. Как только вы поймете, что функция не вернется, потяните ее за ветку, удерживающую вилку. Затем git revert функция fork для применения патча, отменяющего функцию из local- *. При необходимости повторите.
(2) Это то, что вы беспокоитесь о том, что произойдет с патчем в апстриме.
Вам действительно не нужно пока отслеживать, применили ли они ваш патч к remote-stable (, далее r-stable ). Вы не потеряете патч в L-stable, если вы загрузите его из r-stable, а они еще не применили патч.Единственная возможная проблема заключается в том, что в коде из патча будут возникать конфликты слияния, но вы не сможете обойти это. После того, как они применит патч, он либо будет выглядеть точно так же, как вы разрешили конфликты слияния (в этом случае вы не получите различий, когда вы вытащите патч из R-stable), либо они будут слиться другим способом , и вы получите конфликт слияния, и у вас будет возможность решить придерживаться своего или своего пути. Просто помните, что если вы хотите идти своим путем, вы получите ответвление от r-stable. Один из вариантов - перейти «свой путь» на вилку и продолжить свой путь на local- *.