Ветвление GIT — сможем ли мы выжить, используя только мастер?

Количество названий ветвей в основном не имеет значения. Вам придется иметь дело с кодом слияния независимо от того, сколько у вас имен веток — слияние — это просто побочный продукт параллельной работы, когда человек А работает над кодом (в копии репозитория А), а человек Б также работает над кодом. (в копии репозитория B). В какой-то момент кто-то — А, Б, третье лицо или их совокупность — должен работать вместе, чтобы объединить работу, проделанную А и Б.

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

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

Вы можете работать только с одной ветвью, но это не предотвратит слияние — по крайней мере, когда в коде участвует более одного разработчика. На самом деле вы обнаружите, что слияние происходит гораздо чаще, когда все работают над одной и той же веткой, скажем, master, потому что каждый раз, когда вы хотите push, вы сначала должны интегрировать изменения вышестоящего уровня. Всякий раз, когда вы говорите git pull, чтобы получить вклад вашего коллеги в вашу рабочую ветку, git фактически делает fetch, за которым следует merge.

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

Git очень хорош в слиянии. Вам не нужно этого бояться.

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

С учетом этого, могут ли быть какие-то проблемы с наличием только одной главной ветки в разных средах, чтобы нам не приходилось иметь дело с объединением кода между разными ветвями? Я не видел много примеров моделей только с одним мастером, поэтому не уверен, что получится.

Вы мало что знаете об этом, потому что он отбрасывает одну из сильных сторон Git, дешевые ветки и простые слияния. Вы по-прежнему будете объединяться, потому что push и pull должны будут объединить ваш локальный мастер с удаленным мастером, но когда все будут толкать и тянуть к master, когда им захочется, все работы смешаются вместе, и master превратится в беспорядок.

Но ты на правильном пути. Вместо того, чтобы избегать ветвей, вы хотите избегать длительных ветвей. Нет develop или qa ветвей. Наличие master в качестве единственной долго работающей ветки — хороший рабочий процесс.

Хитрость заключается в том, чтобы никогда не выполнять фиксацию напрямую в master. Вместо этого вы всегда хотите работать с короткоживущими "ветвями функций", которые объединяются в master. Ветвь функций, судя по названию, предназначена для одной четко определенной функции (или ошибки). Вся работа и контроль качества для этой функции происходят в ветке функций. После завершения он объединяется в master. master можно запустить прямо в производство или пометить конкретные выпуски.

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

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

Основной рабочий процесс выглядит так...

1. Обновите свой master: git checkout master; git pull --rebase
2. Создайте и проверьте ветку функции для вашей функции: git checkout -b issue/#123
3. Редактируйте, работайте и фиксируйте свою функциональную ветку.
4. Periodically keep up to date with master.
   1. Bring your master up to date.
   2. Перепишите свою работу поверх master: git checkout issue/#123; git rebase master
5. When your work is finished, tested, gone through QA, etc...
   1. Bring your master up to date.
   2. Перепишите свою работу поверх master.
   3. Проверьте свою ветку в прошлый раз. Это будет точно такой же код, как и после слияния, потому что сливать нечего.
   4. Объедините его в master. Это слияние ничего не меняет, вы уже в курсе, но это важно для истории: git checkout master; git merge --no-ff issue/#123
6. Удалите свою ветку функций: git branch -d issue/#123
7. Перейти к 1

Обратите внимание, что обновления выполняются с помощью rebase. Это позволяет избежать кучи «бухгалтерских» слияний, запутывающих историю. Вместо этого с rebase вы делаете вид, что ваша ветка была написана на последней master все это время. Я рекомендую вам установить это в вашем .gitconfig

[pull]
        rebase = preserve

Тогда git pull всегда выполняется как перебазирование, но сохраняет ветки. Это абсолютно безопасно.

Окончательное реальное слияние выполняется с помощью --no-ff (без быстрой перемотки вперед), чтобы гарантировать, что слияние выполнено, поэтому ветвь сохраняется в истории. Коммит слияния также является местом, где можно написать, о чем была ветка, и предоставить ссылку на проблему, которую она решила.

В результате получается история, которая выглядит так:

                            J - K - L [issue/#123]
                           /
A ---------- E ---------- I [master]
 \         /  \         /
  B - C - D    F - G - H

Это две завершенные функции B - C - D и F - G - H и одна открытая ветвь функции J - K - L. Ветви все еще существуют для археологических целей, «пузыри функций», поэтому будущие разработчики знают, что B-C-D были выполнены как единое целое, и могут ссылаться на фиксацию слияния E для получения дополнительной информации. И, несмотря на всю разветвленность, история линейна; git log сообщит о коммитах в правильном порядке.

Это требует больше работы, чем просто фиксация master, но в результате получается чистая, простая история, высококачественный master, на котором можно основывать свою работу, а разработчики избегают столкновений друг с другом. Контроль версий — это такой же инструмент, как ваш редактор или оболочка, и для его эффективного использования требуется немного усилий.