Вопрос по git, branch, git-branch – Как работать одновременно с несколькими разными версиями файлов с помощью git?

9

В настоящее время я работаю над своим собственным набором инструментов для нейровизуализации, который работает под MATLAB / SPM8, и большинство программных файлов в моем хранилище - MATLAB.*.m файлы. У меня есть разные ветки и одинanalysis ветка, которую я использую для текущих анализов с использованием текущей версии. В то же время я разрабатываю код вmaster и ветви функций, которые затем постоянно объединяются вmaster ветка.

Теперь проблема в том, что анализы, в которых я работаюanalysis ветвь занимает много времени (даже дней), и в течение этого времени я не могуgit checkout master или жеgit checkout new-feature, Это серьезно ограничивает мою производительность.

Таким образом, поскольку невозможно одновременно держать несколько веток открытыми, Я думаю переместитьanalysis перейти из репозитория разработки в собственный репозиторий. Вопрос в том, что если яgit init новый репозиторий на основе текущегоanalysis ветка, есть ли способ как-тоgit merge время от времени от текущегоmaster ветку (репозитория разработки), чтобы можно было использовать недавно разработанный код моего репозитория разработки в новом репозитории анализа?

На самом деле, выcan держите несколько веток открытыми одновременно:git working on two branches simultaneously sleske

Ваш Ответ

2   ответа
8

git clone ваш существующий репозиторий в новый репозиторий, вы можете затемgit push или жеgit fetch от одного к другому, чтобы соответствовать ссылкам (веткам), которые вы изменили; нет слияний. Содержимое репозитория будет автоматически жестко связано для экономии места на диске.

Если вы используете--mirror возможностьgit clone а такжеgit pushвы пропустите ветки удаленного слежения и будете иметь одинаковые ветки в обоих, что проще и симметричнее, но меньше обычного использования git. Для максимального & quot; следуйте инструкциям & quot; простота, вместо этого устроить третий "центральный" хранилище (которое должно быть создано--bare) которые оба ваших рабочих репозитория являются клонами.

Никаких слияний (кроме «быстрых слияний», которые на самом деле не сливаются, но необходимо заменить старую ветвь на новую ветвь), потому что вы работаете с теми же ветвями; у вас просто две копии. Когда ваш анализ завершен, и вы можете обновить ветку анализа, простоgit merge --ff-only master пока вanalysis; Вы можете сделать это в любом удобном хранилище, но не забудьте синхронизировать изменения сgit push other-repository.

Другой вариант (начиная с Git версии 2.5) - этоgit worktree команда, которая позволяет несколько независимых рабочих деревьев, в которых вы можетеgit checkoutи т. д., самостоятельно. Разница между этим и описанным выше вариантом создания клона заключается в том, что здесь есть только один наборbranches.

Однако (начиная с версии 2.8) это все еще считается & # x201C; экспериментальным & # x201D; особенность, и я лично не использовал это, чтобы прокомментировать его надежность и полезность.

Спасибо, это мне очень помогает. nrz
Если единственное, что вы когда-либо делаете сanalysis ветвь слияния сmaster вanalysis тогда да, эта ветвь не должна нигде жить, кроме хранилища для анализа. На самом деле, это не обязательно должна рассматриваться как отдельная ветвь: это всего лишь одна-единственная ветвь в этом хранилище, сorigin/master как вверх по течению. Каждое слияние с ним должно быть ускоренным.
Слияние со старого (разрабатываемого) репо (origin/master) к анализу репо: в новомgit clone& gt; d хранилище (без--mirror или любые другие специальные флаги)git merge master (с или без--ff-only флаг) не проходит:fatal: 'master' does not point to a commit, в то время какgit merge --ff-only origin/master даетfatal: Not possible to fast-forward, aborting. (Я думаю--ff-only не удается, потому чтоanalysis ветвь также имеет собственные коммиты, связанные с параметрами анализа и т. д.), но в любом случаеgit merge origin/master работает хорошо, используя «рекурсивный»; стратегия слияния. nrz
Это кажется хорошей идеей. Если яgit clone мой репозиторий (без--mirrorпотому что я использую Dropbox как частный репозиторий удаленного отслеживания, как объясненоfor example here) можно ли создавать новые ветви и синхронизировать их? Если я создаю новую ветвь функции, я должен создать ее с тем же именем в обоих моихoriginal хранилище и в новомanalysis хранилище? Или достаточно создать его только вoriginal хранилище, если я всегда сливаю толькоmaster филиалoriginal хранилище для новогоanalysis хранилище? nrz
2

как объяснил Кевин Рид, вы также можете просто использоватьgit-new-workdir создать вторую рабочую копию для вашего репо. Таким образом, обе рабочие копии всегда будут автоматически видеть одни и те же ветви, потому что они используют один репозиторий git.

Преимущество перед клонированием репо состоит в том, что нет необходимости в какой-либо ручной синхронизации / объединении. В тот момент, когда вы фиксируете в рабочем каталоге A, фиксация будет отображаться в рабочем каталоге B (например,git log).

Только предостережение: когда вы изменяете репозиторий (фиксация, перебазирование, сброс ветки и т. Д.), Вы не должны проверять ту же ветку в другом рабочем каталоге, иначе git будет немного запутан (см.git-new-workdir: фиксация в рабочем дереве A вызывает фиктивные изменения в дереве B ).

Увидеть:Git работает на двух ветвях одновременно

Похожие вопросы