Бранчи в (d)vcs

[phd_ru]

Коллеги, пара вопросов. Возможно, вы поможете мне найти более лучшие способы работы, чем я сейчас использую.

Вопрос номер 1. Я делаю макет работающей программы (использую git). Это именно макет — по сравнению с тем, как должна будет работать программа, там много урезано. Но значительная часть кода в макете должна быть как в настоящей программе. Я сейчас делаю так. Создал в своём репозиторий ветку, скажем, stand. Это временная ветка, потому что макет потом умрёт, а часть кода из него должна будет остаться в основной программе, поэтому я этой ветке не делаю push в общий репозиторий. Пишу какой-то код в ветку master, потом переключаюсь в stand, делаю merge, отлаживаю, в master, пишу код, в stand, merge… Довольно утомительные переключения.

Время от времени мне надоедает видеть сплошной поток merge-коммитов в ветке stand, и я начинаю с чистого листа. Делаю

git diff master > patch

, удаляю мой репозиторий целиком, на его место копирую «чистый» репозиторий с одним master'ом, создаю stand, накладываю patch, делаю commit. И далее опять — master, commit, stand, merge…

Я наверняка это делаю неправильно и для моего сценария есть какие-то более удобные способы работы. Посоветуйте, а?

Вопрос № два. У меня есть множество компьютеров, на которые я регулярно логинюсь. И на них слегка разная конфигурация, соответственно, и dot-файлы отличаются. Скажем, разные списки почтовых ящиков в переменной MAILPATH и файле .muttrc, разные сигнатуры в почте в том же .muttrc, и т.д. и т.п. Пяток наиболее отличающихся и часто меняющихся файлов (.profile, .procmailrc, .muttrc) требуют особенного внимания. Сейчас я обхожусь с ними просто — собрал их в несколько директорий и сделал diff с «master»-файлами. Когда я меняю master, запускаю скрипт, который копирует master во все директории и накладывает патчи. Исправляю конфликты, обновляю патчи и раскидываю файлы по своим компьютерам (всё, кроме конфликтов, автоматизировано скриптами, конечно).

И опять — может, есть более удобные способы? Не поможет ли мне здесь (d)vcs? Скажем, держать master-файлы в trunk (default, master), и несколько бранчей для разных компьютеров. При изменении master делать merge во всех ветках. После изменения делать push на удалённые компьютеры. И может быть там даже создать какой-нибудь hook, который после push сам выставит изменённые файлы?

Upd. В другом форуме (в BUG-листе) мне посоветовали писать и отлаживать код в ветке stand, и использовать git cherry-pick для переноса в master. В самом деле, так оказалось удобнее. Командой git cherry -v master смотрю, что надо переносить из отладочной ветки, git cherry-pick переносит.

Относительно dot-файлов мне ещё посоветовали держать их не в ветках, а в отдельных репозиториях. Тогда merge будет делаться автоматически в процессе pull.

Upd2. Ещё относительно dot-файлов мне напомнили старый проверенный способ — общего вида файл и к нему специфичные дополнения, читающиеся по include/source.

Upd3. У cherry/cherry-pick оказались свои тонкости. Во-первых, если ветки не были заранее связаны между собой, приходится каждый раз явно указывать, с какой веткой сравнивать: не

git cherry -v

, а

git cherry -v master

. Во-вторых, после "сбора вишен" перенесённые патчи показываются в списке cherry — git считает, что их не хватает в ветке stand.

Я пошёл таким путём. Сделал ветку master upstream для stand:

git branch --track stand

. Теперь команда cherry в stand не требует указания, с чем сравнивать. Во-вторых, после переноса коммитов в master они "переносятся" обратно в stand командой

git pull --rebase

(опять не надо указывать master, потому что stand помнит, что он происходит от master); "переносятся" в кавычках, потому что git обнаруживает, что код уже на месте, но запоминает, что эти коммиты были перенесены из master, и больше не показывает их в cherry.

Upd4. После cherry-pick вместо

git co stand
git pull --rebase

я стал делать

git rebase master stand

. Это и проще, и правильней. Проще, потому что эта одна команда эквивалентна двум

git co stand
git rebase master

, а правильней, потому что в ней упор делается на rebase, а не на pull.

PS. Первый раз я по-настоящему понял, зачем нужен rebase и как им пользоваться!