Git на самом деле не о ветвях . Это действительно около коммитов . Ветви или, если быть точным, имена ветвей - это просто способ найти коммитов. Это коммиты имеют значение.
Если вы задаете вопрос следующим образом: Могут ли два разных коммита содержать файлы с одинаковым именем, но с разным содержимым? ответ ясно: да, они могут.
Как только вы зададите очевидный дополнительный вопрос: При двух разных коммитах, в которых файл F имеет разное содержимое, когда я сливаю эти commits, что происходит с содержимым F? вы видите, где начинает возникать проблема.
В Git слияние составляет объединение работы . Поскольку каждый коммит представляет снимок файлов, Git требуется третий коммит здесь. Этот третий коммит представляет собой общий общий коммит, который находится в обеих ветвях. Помните, что в Git фиксация часто происходит на многих ветвях одновременно . Фраза на ветке просто означает, что, используя имя ветви - tip commit ветки - и работая в обратном направлении, мы получаем соответствующий коммит.
Следовательно, если у нас есть строка коммитов, которая расходится:
I--J <-- branch1
/
...--G--H
\
K--L <-- branch2
, мы можем рассмотреть объединение работы , начав с общего общего коммита H, который содержит снимок всех файлов. Мы сравниваем этот снимок в H со снимком в J. Если файл F изменился с H на J, это изменение. Далее мы сравниваем снимок в H с снимком в L. Если файл F изменился здесь, это изменение. Git теперь будет объединять изменения .
Если изменения "настроить систему на односторонние действия" и "настроить систему на другие действия", эти изменения могут конфликтовать , Будут ли и как они конфликтовать, зависит от того, как работает конфигурация. Git понимает только строк . Если строка 47 файла F в коммите H изменяется в J и L и изменяется по-разному , это конфликт. Если только в commit J есть изменение в строке 47, Git считает, что все в порядке, чтобы принять это изменение от J.
Я хочу сохранить неизмененные файлы конфигурации в каждой ветке все время. Кто-нибудь знает, как мне этого добиться?
Обычный ответ: даже не пытайтесь. Эти файлы не должны зависеть от ответвления , потому что когда у вас есть это:
...--G--H <-- master, dev
файлы в коммите H одинаковы, независимо от того, используете ли вы коммит H из-за имени master или из-за имени dev. Оба имени ветви идентифицируют один и тот же коммит H.
Вместо этого сделайте эти файлы конфигурации неотслеживаемыми (и, вероятно, также игнорируемыми ). Это означает, что Git никогда не обращает на них никакого внимания. Они не изменятся, когда вы переключаетесь с одного коммита на другой, или когда вы переключаетесь с одной ветви на другую, даже если это означает, что переключение коммитов тоже.
Делайте вещи на основе учетных данных и базы данных в разные рабочие деревья . Каждый репозиторий Git поставляется с рабочим деревом, так что вы можете просто использовать два разных клона одного и того же базового репозитория, чтобы легко получить два разных рабочих дерева.
Если ваш Git равен как минимум 2,5 ( и желательно, по крайней мере, 2,15 из-за довольно большой ошибки, которая не была исправлена до этого момента), вы можете использовать один Git репозиторий с git worktree add, чтобы добавить второе рабочее дерево в один репозиторий.
Если вы действительно настаиваете на том, чтобы делать все это в одном репозитории и изменять файлы в зависимости от того, какую ветвь name вы указали в недавней команде git checkout или git switch, подумайте об использовании хука после проверки. Вы можете написать любой код, который вам нравится, в таком хуке, и вы можете прочитать название ветки, которая использовалась здесь. Это болезненно и сопряжено с трудностями: метод отдельного рабочего дерева намного эффективнее, если вы можете позволить себе место на диске.