Использование Git для обновления одного файла с изменениями, внесенными во второй файл

Question

Я новичок в Git; Я знаю основные команды, но я не так хорошо знаком с оптимальным способом организации проектов.

У меня есть две версии файла, которые делают одно и то же. Единственное различие между этими двумя файлами заключается в том, что они сканируют определенный файл, и различия ограничиваются одной областью кода. Добавляя функциональность к одному, я мог просто скопировать и вставить те же самые изменения во второй файл, но я думаю, что это то, что должно упростить хороший контроль версий.

Мое лучшее предположение состоит в том, что я должен создать вторую ветвь (скажем, 'branch_B') и сохранить копию файла с одинаковым именем как в branch_A, так и в branch_B (чтобы их можно было легко объединить). Но тогда, когда я объединяюсь, не получу ли я странную комбинацию двух файлов в основной ветке, а не обновленную версию второго файла?

Answer 1

Чтобы избежать дублирования кода, вы должны сделать рефакторинг своего кода. Контроль версий не может заменить это.

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

См .: Повторное использование кода

Answer 2

Я подтверждаю, что:

• , если вы вносите изменения в f.txt (branch A)
• , объединяете с веткой B

только new об изменениях с f.txt-branchA будет сообщено как f.txt-branchB.

Часть с существующими отличиями не будет затронута слиянием.
(чтоесли ваши изменения не находятся непосредственно в этой «одной области кода»)

Answer 3

Сохранить вариант A в основной ветви и вариант B в branch_B.Всякий раз, когда вам нужно внести изменения в файл, сделайте их в варианте A и объедините их в branch_B.В branch_B сохраняйте дополнительный коммит (или несколько), который содержит все изменения, которые отличают branch_B.

совет honk реорганизовать ваш код в целом - хороший совет, однако я понимаю, что иногда это просто не таквозможно.