LINUX.ORG.RU

две ветки с одинаковыми файлами, во второй дополнительные

 ,


0

2

Есть репозиторий git. В нем есть файлы проекта + куча отладочного шлака. Каким образом можно разнести этот каталог на две ветки, где в одной ветке лишь чистые файлы проекта, а во второй эти же файлы + отладочные файлы? Как это грамотно синхронизировать, когда разработчик поработав в ветке с отладочными потом перенес лишь обновленные файлы проекта в первую ветку?

★★★★★

Последнее исправление: I-Love-Microsoft (всего исправлений: 1)

Весьма странный подход к разработке. Даже не знаю, как бы всё это организовывал. Наверное, отладочный шлак убрал бы вообще из под версионирования и мерджил/черрипикал как обычно.

Ну или разделял комиты на те, которые можно черепикнуть/смерджить без последствий (изменения в файлах проекта) и на те, которые относятся к изменениям в отладочных файлах.

Ещё можно .gitattributes -> merge=ours поковырять.

Может другие пользователи форума что-то более дельное предложат.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)

Самый простой способ если речь идет о файлах

git checkout release_branch
git checkout debug_branch path/to/updated/file
git commit -m "Merged debug_branch"
alx777 ★★
()

Попробовать, например перенести отладочный набор в gitignore, а там уже отдельную репу «dev-files»

swwwfactory ★★
()
Ответ на: комментарий от swwwfactory

Но отладочные файлы тоже не надо терять, их изменения надо отслеживать, в том числе и когда меняются и отладочные и финальные одновременно для одного коммита.

upd: понял, отдельная суб-репа, это мысль

а можно чтобы эта субрепа ссылалась на тот же репозиторий но другую ветку, отладочную?

I-Love-Microsoft ★★★★★
() автор топика
Последнее исправление: I-Love-Microsoft (всего исправлений: 2)

Можно вынести «шлак» в отдельную репу и подтягивать через subtree merge

annulen ★★★★★
()

Сделать две ветки. Одну development, вторую production. В первой оставить всё, как есть, во второй игнорить всё ненужное.

shell-script ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Да, такое можно провернуть для subtree. Просто тянешь subtree определенной ветки (настраиваешь биндинг пула (git remote -v)), но если это будет лежать в gitignore, то можно наверное например так:

proj
  priv
    .gitignore
    dev-files --> смотрит в свою репу A (это не subtree)
  src
    dev-files-sources-subtree --> то-же самое что dev-files, 
                                  только "определенный срез"
                                  из репы A

swwwfactory ★★
()
Ответ на: комментарий от shell-script

Точно, хорошая мысля, не знал что gitignore может быть разных у веток. Но как это скажется если мержить файлы из ветки где они «легальны» в ветку где они «незаконны»? Они просто отбросятся? Я думал gitignore лишь чтобы всякие широкие команды типа add не добавляли их автоматом, но спасет ли это при merge?

I-Love-Microsoft ★★★★★
() автор топика
Ответ на: комментарий от I-Love-Microsoft

Ну вот только что проверил.

Конфиг репы.

└─> cat .git/config 
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        excludesfile = +info/exclude 

[branch "production"]
        excludesfile = +info/exclude_from_production

[remote "production"]
        excludesfile = +info/exclude_from_production

[local "production"]
        excludesfile = +info/exclude_from_production

Общий игнор

└─> cat .git/info/exclude
# git ls-files --others --exclude-from=.git/info/exclude
# Lines that start with '#' are comments.
# For a project mostly in C, the following would be a good set of
# exclude patterns (uncomment them if you want to use them):
# *.[oa]
# *~

Игнор для production

└─> cat .git/info/exclude_from_production 
#
*.t

Пробую мержить.

└─> git checkout devel 
Переключено на ветку «devel»
└─> ls
code.c  debug.t  init
└─> git checkout production 
Переключено на ветку «production»
└─> ls
code.c  init
└─> git merge devel production 
Already up-to-date.
└─> ls
code.c  init

Вроде бы всё работает.

shell-script ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.