Создание тэгов // веток в управлении версиями только с некоторыми файлами

Question

Я уже работаю с контрольной версией PVCS, но собираюсь начать новый проект и хотел бы перейти на Git / SVN, сохранив ту же структуру, что и у меня.

Код - Cи он структурирован так, что каждый «объект» C имеет свой собственный тег, в котором для компиляции есть только его файлы C и необходимые файлы H.

Возможно ли в Git / SVN создать ветку изтранк, который содержит только необходимые файлы для этого «объекта» для компиляции, создания тега и объединения изменений в транк?

Я пробовал Git, но каждый раз, когда я создаю ветку, у меня естьвсе файлы, включая файлы C и H из других «объектов», которые мне не нужны.

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

Answer 1

PVCS представляется файлово-ориентированным (например, CVS или RCS), с централизованным хранилищем (например, CVS) и блокировкой (также как CVS).

SVN ориентирован на фиксацию (и централизован), но обрабатывает ветви как поддеревья файлов, с моделью слияния, а не моделью блокировки (хотя на самом деле SVN также предлагает блокировку файлов). В некоторых случаях это может быть совместимым с тем, как вы используете теги. Но это может не произойти: если вы помечаете отдельные файлы по-разному, несмотря на то, что они находятся в одной и той же папке файловой системы, например, dir/sub/file1.c имеет теги A и B, в то время как dir/sub/file2.c имеет совершенно разные теги D и E, это тоже не будет хорошо сочетаться .

Git и другие современные VCS распределены, а не централизованы и ориентированы на принятие. Когда система распределена, сама концепция блокировки файла довольно проста: нет центрального органа, объявляющего, кто имеет блокировку. Так что все они используют модели слияния. Кроме того, Git не имеет понятия trunk: ветви все равны - или, точнее, ветви на самом деле ничего не значат. В Git важен граф коммитов , в котором имена веток действительно являются дополнительным трюком, чтобы вспомнить, как работать с через графом.

(В сочетании с идеей достижимости предоставляет Git возможность отбрасывать нежелательные объекты: в отличие от некоторых других современных систем управления версиями с графическим управлением, коммиты не более особенные, чем любые другие внутренние объекты. Это может быть немного дезориентирующим, мягко говоря: в других ориентированных на коммит VCS, когда вы делаете коммит, он постоянно прикрепляется к одной ветке, и вы всегда можете найти его в этой ветке. Так что Git здесь даже больше, чем скачок скажем, Mercurial.)

Каждый раз, когда у вас есть файлово-ориентированная система контроля версий, отдельные файлы легко выбирать, потому что именно так работает VCS. Как только вы перейдете к модели фиксации, «рабочая область» (как бы она ни называлась в этой конкретной VCS - Git использует фразу work-tree или рабочий каталог или что-то в этом роде ) должен соответствовать конкретному коммиту, поскольку вы не получаете версию V fileX.c, вы получаете все файлы, составляющие версию V. Теоретически можно объединить это с разреженным извлечением и несколькими рабочими областями, так что рабочая область 1 имеет версию V1 из редко извлеченных file1.c, рабочая область 2 имеет версию V2 из редко извлеченных file2.c и т. д .; но вы будете бороться с моделью все время. Это, вероятно, не очень хорошая идея.

В конце концов, я думаю, что если вы не придерживаетесь файлово-ориентированной VCS, вам придется изменить рабочий процесс.

Answer 2

Я не могу говорить о специфике того, как Subversion справится с этим; действительно мерзавец и подрывная деятельность - это совершенно разные вопросы. В целом я могу сказать, что я не верю, что так работают ветви подрывной деятельности.

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

Если вы хотите отслеживать и компилировать наборы файлов отдельно, они должны храниться в отдельных репозиториях и могут быть объединены с «родительским репо», который рассматривает их как подмодули.

В более общем смысле, цель «переключать инструменты, но сохранить структуру из моего текущего инструмента» не очень реалистична. Каждый инструмент управления версиями имеет свою собственную модель проекта, его содержание и историю. Если вам нравится структура, которая у вас есть, вы можете использовать инструмент, который у вас есть. Если инструмент, который у вас есть, работает плохо, это, вероятно, признак структуры, которую использует инструмент.

Answer 3

Хотя в вашем понимании веток с Git есть некоторая путаница, я думаю, это может быть выполнимо.

Во-первых, о ветвях: в Git они являются просто ссылкой на их последний коммит (под капотомветвь - это файл, содержащий только хеш коммита.)

Git, PVCS и SVN работают по-разному.

В Git, если вы хотите разделить файлы на ветку, это возможно (хотя и необычно).Советуем создать базовые ветви следующим образом:

Создайте свой репозиторий git:

ghislain@linux (1): /tmp/example (master) ✔
> git init .
Initialized empty Git repository in /tmp/example/.git/

Создайте свои файлы (хотя они, вероятно, уже есть):

ghislain@linux (1): /tmp/example (master #) ✔
> touch foo.c foo.h bar.c bar.h

Сделайте начальный коммит (который послужит основой для всех ваших веток):

ghislain@linux (1): /tmp/example (master #) ✔
> touch README.md
ghislain@linux (1): /tmp/example (master #) ✔
> git add README.md && git commit -m 'Initial commit'
[master (root-commit) a9a05f3] Initial commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README.md

Создайте ветку для каждого типа файлов с соответствующими файлами:

ghislain@linux (1): /tmp/example (master) ✔
> git checkout -b files-foo master
Switched to a new branch 'files-foo'
ghislain@linux (1): /tmp/example (files-foo) ✔
> git add foo.*
ghislain@linux (1): /tmp/example (files-foo +) ✔
> git commit -m 'foo added'
[files-foo 558cdc6] foo added
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 foo.c
 create mode 100644 foo.h

Сделайте несколькомодификации, обновления, работа с указанными файлами:

ghislain@linux (1): /tmp/example (files-foo) ✔
> vim foo.h
ghislain@linux (1): /tmp/example (files-foo *) ✔
> git add foo.h 
ghislain@linux (1): /tmp/example (files-foo +) ✔
> git commit -m 'foo.h updated'
[files-foo 9565594] foo.h updated
 1 file changed, 1 insertion(+)

Сделайте то же самое для других файлов:

ghislain@linux (1): /tmp/example (master) ✔
> git checkout -b files-bar master
Switched to a new branch 'files-bar'
ghislain@linux (1): /tmp/example (files-bar) ✔
> git add bar.*
ghislain@linux (1): /tmp/example (files-bar +) ✔
> git commit -m 'bar files added'
[files-bar 9f78382] bar files added
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 bar.c
 create mode 100644 bar.h

Ваш журнал фиксации будет выглядеть следующим образом, с одной веткой на файл"type":

ghislain@linux (1): /tmp/example (files-bar) ✔
> git log --graph --oneline --all
* 9f78382 (HEAD -> files-bar) bar files added
| * 9565594 (files-foo) foo.h updated
| * 558cdc6 foo added
|/  
* a9a05f3 (master) Initial commit

Если вы хотите работать с набором файлов, вам нужно будет git checkout <related-branch> и зафиксировать его там.

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

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