Как предотвратить git merge для слияния определенного файла из транка в ветку и наоборот

Question

Я использую git при разработке кода VHDL. Я занимаюсь разработкой компонента в git-ветке: comp_dev. Интерфейс компонента не меняется, только код внутри компонента. Теперь этот компонент уже существует в основной ветке, но в более стабильной версии, достаточной для того, чтобы другие разработчики могли использовать этот компонент. Другие разработчики также имеют ветки для своей работы, и когда их код исправен, они объединяют свои ветви с master.

На этом этапе мне нужно иметь возможность объединить все изменения из master с моей веткой comp_dev, что, в принципе, не проблема, но иногда стабильная версия компонента, над которым я работаю, изменяется как часть других дизайнеров. работать, но не интерфейс. Я должен выполнять git merge вручную - этот файл для каждого конкретного файла каждый раз, когда я хочу объединиться, в противном случае я получаю конфликт, который мне нужно решить вручную, выбрасывая их работу.

То же самое происходит, если я хочу объединить изменения в других файлах обратно в master. Если я забуду выполнить git merge -s oursrr / rx / state_machine.vhd comp_dev перед выполнением git merge, то я получу либо ручное слияние, либо случайное слияние нестабильной версии автомата поверх стабильный.

Есть ли способ временно исключить один файл из слияний?

Answer 1

Я разместил решение, которое работает для меня здесь

Answer 2

Если я правильно понимаю, вы хотите отложить внесение изменений в упомянутый компонент (назовем его 'C'), в то время как ваша работа сосредоточена на каком-то другом модуле. Побочным эффектом вашей работы являются незначительные изменения в «C», которые могут конфликтовать с работой других людей, но вам не нужно беспокоиться о том, чтобы сливать «C» каждый раз, когда вы переносите фокус-работу туда, где находится ваш «мастер» является.

AFAIK, набор изменений в git является атомарным и не знает о файлах; поэтому невозможно исключить файл из слияния, если только не разрешить конфликт слияния в пользу ревизии, которую вы предпочитаете.

Может быть и другой выход из вашей ситуации.

Вы, вероятно, хотите выделить «C» в отдельную библиотеку и иметь для нее отдельный репозиторий git. Ваш проект будет разбит на несколько репозиториев. Но не бойтесь, git позволит вам управлять этим через подмодули.

Проверьте здесь , чтобы узнать, как это сделать.

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

Что касается управления параллельными изменениями, обычная позиция с управлением версиями с открытым исходным кодом состоит в том, что VC не заменяет общение с членами команды. Согласитесь с общим подходом к разработке, сведите к минимуму одновременные несовместимые изменения, и процесс разработки станет менее болезненным.

Answer 3

Я начал использовать git merge --no-commit --no-ff other_branch, как упомянуто в:

https://gist.github.com/katylava/564416

хотя я не делаю это во временной ветке, просто в моей рабочей ветке функций.

Это требует от вас немного больше работы, выбирая коммиты, которые вы хотите сохранить, и отбрасывая остальные, но, по крайней мере, вы точно знаете, что держите и что выбрасываете.

Answer 4

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

Перебазировка и слияние могут быть не слишком полезны для того, что вы пытаетесь сделать. Более безопасный, простой, скучный и, в противном случае, более предсказуемый подход к извлечению только определенных битов кода или определенных файлов будет использовать предоставленные git методы для ручного перемещения патчей, такие как (a) выбор вишни для отдельных коммитов или (b) format-patch и есть. Если вам нужно настроить результат (например, удалить файл), сделайте это и объясните, почему в новом коммите. Или просто подправьте материал, пока вы собираете вишню или накладываете заплатки. am может быть --interactive, а вишня может быть изменена с помощью коммита --amend.

Я попробовал еще одну тактику с давней веткой: объединить все, затем вручную вернуть то, что я действительно не хотел объединять. Это тоже хорошо работало.

Что-то еще, что кажется отличной идеей, это с использованием мелкозернистых ветвей .

Полагаю, мне кажется, что одно из ключевых сообщений о том, что уделять внимание коду и часто проводить хорошие автоматические тесты, важнее, чем освоение конкретной стратегии git patch / merge.