Таксономия веток Git

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

В настоящее время у нас есть только ветка владелец с такой классификацией файлов:

  1. / html /
    • file.html
  2. / css /
    • file.css

Однако мы решили создать ветку разработки и среду Gulp. Для этого я создал новую ветку и внес необходимые изменения. Новая ветка выглядит так

  1. / dist /
    • / html /
      • file.html
    • / css /
      • file.css
  2. / src /
    • / scss /
      • file.scss
  3. gulpfile.js

К сожалению, в процессе я не осознал, что сделал такие огромные изменения, и теперь у меня есть сомнения относительно следующих шагов. Итак, мои основные вопросы:

  1. Повлияет ли фиксация этой новой файловой структуры в ветке на мастер?
  2. При слиянии с мастером возникнут ли проблемы с этими файлами, что означает, что они, вероятно, будут дублировать их, и у меня будут все папки в моем проекте (html, css, dist, src)?

Спасибо за все ответы.


44
1

Ответ:

Переход в ветку разработки не повлияет на мастер.

При слиянии ветки разработки с мастером все изменения, внесенные в ветку разработки, будут включены в мастер. Добавление новых папок / файлов - это изменение. Это не «дублирует» файлы как таковые - git сохраняет единственную копию любого заданного содержимого. Но дополнительный контент будет добавлен в главную ветку.

Иногда люди пытаются «исправить» это, удаляя лишние папки во время слияния в мастер. Затем в следующий раз, когда им придется объединить master (или строку изменений, созданных в master) со своей веткой разработки, они обнаруживают, что git пытается удалить все эти вещи из разработки (и, в лучшем случае, они получают кучу конфликтов слияния, которые надоедает убирать).

По этой причине лучше думать о ветвях как о разные версии одного и того же контента, а не о различных подмножествах контента. Обычно попытки рассматривать master как подмножество разработки указывают на то, что вы пытаетесь использовать git в качестве инструмента сборки и развертывания, что на самом деле не является его ролью. (В некоторых простых случаях использования git можно использовать для развертывания, и некоторым это нравится, потому что они считают его «простым»; но это не то, для чего он предназначен, он имеет небольшую гибкость, поэтому я не рекомендую его.)