в каком устройстве хранится код команды
Регистр команд
Текущая команда находится в специально для нее отведенном регистре команд. В процессе работы с текущей командой увеличивается значение так называемого счётчика команд, который теперь указывает на следующую команду (если, конечно, не было команды перехода или останова).
Часто команду представляют как структуру, состоящую из записи операции (которую требуется выполнить) и адресов ячеек исходных данных и результата. По адресам указанным в команде берутся данные и помещаются в обычные регистры (в смысле не в регистр команды), получившийся результат тоже сначала оказывается в регистре, а уж потом перемещается по своему адресу, указанному в команде.
Связанные понятия
Сопрограммы (англ. coroutines) — методика связи программных модулей друг с другом по принципу кооперативной многозадачности: модуль приостанавливается в определённой точке, сохраняя полное состояние (включая стек вызовов и счётчик команд), и передаёт управление другому. Тот, в свою очередь, выполняет задачу и передаёт управление обратно, сохраняя свои стек и счётчик.
ПИН (англ. Personal Identification Number — персональный идентификационный номер) — аналог пароля. В ходе авторизации операции используется одновременно как пароль доступа держателя карты к терминалу (банкомату) и как секретный ключ для цифровой подписи запроса. ПИН предусматривается для кредитных и подобных карт (например, сим-карт); с его помощью производится авторизация держателя карты. ПИН должен знать только держатель карты. Обычно предусмотрено ограничение попыток правильного ввода (в основном.
В каком устройстве хранится код команды
Самый основной элемент компьютера, это, конечно, процессор. Давайте подробней его рассмотрим. Упрощённая структура процессора (рис. 4):
Рис. 4. Упрощённая структура процессора
Основные элементы процессора:
· Регистры – это специальные ячейки памяти, физически расположенные внутри процессора. В отличие от ОЗУ, где для обращения к данным требуется использовать шину адреса, к регистрам процессор может обращаться напрямую. Это существенно ускорят работу с данными.
· Арифметико-логическое устройство выполняет арифметические операции, такие как сложение, вычитание, а также логические операции.
· Блок управления определяет последовательность микрокоманд, выполняемых при обработке машинных кодов (команд).
2.2. Режимы работы процессора.
Процессор архитектуры x86 может работать в одном из пяти режимов и переключаться между ними очень быстро:
1. Реальный (незащищенный) режим (real address mode) — режим, в котором работал процессор 8086. В современных процессорах этот режим поддерживается в основном для совместимости с древним программным обеспечением (DOS-программами).
2. Защищенный режим (protected mode) — режим, который впервые был реализован в 80286 процессоре. Все современные операционные системы (Windows, Linux и пр.) работают в защищенном режиме. Программы реального режима не могут функционировать в защищенном режиме.
3. Режим виртуального процессора 8086 (virtual-8086 mode, V86) — в этот режим можно перейти только из защищенного режима. Служит для обеспечения функционирования программ реального режима, причем дает возможность одновременной работы нескольких таких программ, что в реальном режиме невозможно. Режим V86 предоставляет аппаратные средства для формирования виртуальной машины, эмулирующей процессор8086. Виртуальная машина формируется программными средствами операционной системы. В Windows такая виртуальная машина называется VDM (Virtual DOS Machine — виртуальная машина DOS). VDM перехватывает и обрабатывает системные вызовы от работающих DOS-приложений.
4. Нереальный режим (unreal mode, он же big real mode) — аналогичен реальному режиму, только позволяет получать доступ ко всей физической памяти, что невозможно в реальном режиме.
5. Режим системного управления System Management Mode (SMM) используется в служебных и отладочных целях.
При загрузке компьютера процессор всегда находится в реальном режиме, в этом режиме работали первые операционные системы, например MS-DOS, однако современные операционные системы, такие как Windows и Linux переводят процессор в защищенный режим. Вам, наверное, интересно, что защищает процессор в защищенном режиме? В защищенном режиме процессор защищает выполняемые программы в памяти от взаимного влияния (умышленно или по ошибке) друг на друга, что легко может произойти в реальном режиме. Поэтому защищенный режим и назвали защищенным.
2.3. Регистры процессора (программная модель процессора).
Для понимания работы команд ассемблера необходимо четко представлять, как выполняется адресация данных, какие регистры процессора и как могут использоваться при выполнении инструкций. Рассмотрим базовую программную модель процессоров Intel 80386, в которую входят:
· 8 регистров общего назначения, служащих для хранения данных и указателей;
· регистры сегментов — они хранят 6 селекторов сегментов;
· регистр управления и контроля EFLAGS, который позволяет управлять состоянием выполнения программы и состоянием (на уровне приложения) процессора;
· регистр-указатель EIP выполняемой следующей инструкции процессора;
· система команд (инструкций) процессора;
· режимы адресации данных в командах процессора.
Начнем с описания базовых регистров процессора Intel 80386.
Базовые регистры процессора Intel 80386 являются основой для разработки программ и позволяют решать основные задачи по обработке данных. Все они показаны на рис. 5.
Рис. 5. Базовые регистры процессора Intel 80386
Среди базового набора регистров выделим отдельные группы и рассмотрим их назначение.
2.4. Регистры общего назначения.
2.5. Сегментные регистры.
В отличие от DS, ES, GS, FS, которые называются регистрами сегментов данных, CS и SS отвечают за сегменты двух особенных типов – сегмент кода и сегмент стека. Первый содержит программу, исполняющуюся в данный момент, следовательно, запись нового селектора в этот регистр приводит к тому, что далее будет исполнена не следующая по тексту программы команда, а команда из кода, находящегося в другом сегменте, с тем же смещением. Смещение очередной выполняемой команды всегда хранится в специальном регистре EIP (указатель инструкции, 16-битная форма IP), запись в который так же приведет к тому, что далее будет исполнена какая-нибудь другая команда. На самом деле все команды передачи управления – перехода, условного перехода, цикла, вызова подпрограммы и т.п. – и осуществляют эту самую запись в CS и EIP.
Рис. 6. Регистр флагов FLAGS.
CF – флаг переноса. Устанавливается в 1, если результат предыдущей операции не уместился в приемнике и произошел перенос из старшего бита или если требуется заем (при вычитании), в противном случае – в 0. Например, после сложения слова 0 FFFFh и 1, если регистр, в который надо поместить результат, – слово, в него будет записано 0000 h и флаг CF = 1.
PF – флаг четности. Устанавливается в 1, если младший байт результата предыдущей команды содержит четное число битов, равных 1, и в 0, если нечетное. Это не то же самое, что делимость на два. Число делится на два без остатка, если его самый младший бит равен нулю, и не делится, когда он равен 1.
AF – флаг полупереноса или вспомогательного переноса. Устанавливается в 1, если в результате предыдущей операции произошел перенос (или заем) из третьего бита в четвертый. Этот флаг используется автоматически командами двоично-десятичной коррекции.
ZF – флаг нуля. Устанавливается в 1, если результат предыдущей команды – ноль.
SF – флаг знака. Он всегда равен старшему биту результата.
TF – флаг ловушки. Он был предусмотрен для работы отладчиков, не использующих защищенный режим. Установка его в 1 приводит к тому, что после выполнения каждой программной команды управление временно передается отладчику.
IF – флаг прерываний. Сброс этого флага в 0 приводит к тому, что процессор перестает обрабатывать прерывания от внешних устройств. Обычно его сбрасывают на короткое время для выполнения критических участков кода.
DF – флаг направления. Он контролирует поведение команд обработки строк: когда он установлен в 1, строки обрабатываются в сторону уменьшения адресов, когда DF =0 – наоборот.
OF – флаг переполнения. Он устанавливается в 1, если результат предыдущей арифметической операции над числами со знаком выходит за допустимые для них пределы. Например, если при сложении двух положительных чисел получается число со старшим битом, равным единице, то есть отрицательное, и наоборот.
Флаги IOPL (уровень привилегий ввода-вывода) и NT (вложенная задача) применяются в защищенном режиме.
2.7. Цикл выполнения команды
Программа состоит из машинных команд. Программа загружается в оперативную память компьютера. Затем программа начинает выполняться, то есть процессор выполняет машинные команды в той последовательности, в какой они записаны в программе.
Для того чтобы процессор знал, какую команду нужно выполнять в определённый момент, существует счётчик команд – специальный регистр, в котором хранится адрес команды, которая должна быть выполнена после выполнения текущей команды. То есть при запуске программы в этом регистре хранится адрес первой команды. В процессорах Intel в качестве счётчика команд (его ещё называют указатель команды) используется регистр EIP (или IP в 16-разрядных программах).
Счётчик команд работает со сверхоперативной памятью, которая находится внутри процессора. Эта память носит название очередь команд, куда помещается одна или несколько команд непосредственно перед их выполнением. То есть в счётчике команд хранится адрес команды в очереди команд, а не адрес оперативной памяти.
Цикл выполнения команды – это последовательность действий, которая совершается процессором при выполнении одной машинной команды. При выполнении каждой машинной команды процессор должен выполнить как минимум три действия: выборку, декодирование и выполнение. Если в команде используется операнд, расположенный в оперативной памяти, то процессору придётся выполнить ещё две операции: выборку операнда из памяти и запись результата в память. Ниже описаны эти пять операций.
Суммируем полученные знания и составим цикл выполнения команды:
Это упрощённый цикл выполнения команды. К тому же действия могут отличаться в зависимости от процессора. Однако это даёт общее представление о том, как процессор выполняет одну машинную команду, а значит и программу в целом.
Система кодирования команд. Способы адресации
Система кодирования команд
Запись любой команды определяется ее форматом. Формат команды – это структура команды, позволяющая распознать назначение отдельных ее полей.
Схема выполнения трехадресной команды имеет вид:
Здесь ADD – код операции сложения.
Формат двухадресной команды представлен на рис.11.1,б. Выполнение операции с помощью такой команды проходит по следующей схеме:
Выполнение того же самого действия c = a + b в двухадресной системе кодирования команд потребует уже двух команд, например:
Одноадресная команда имеет формат, приведенный на рис.11.1,а. Обычно ЭВМ с одноадресной системой команд имеют особую структуру, в состав которой входит специальный регистр ( регистр результата – РР ). Он служит для хранения результата операции и используется в качестве одного из операндов при выполнении операции ( рис. 11.2).
Схема выполнения операции на ЭВМ с одноадресной системой команд имеет вид:
Операцию c = a + b в одноадресной системе команд можно выполнить следующим образом:
Взаимозависимость формата команды и основных параметров ЭВМ
Важной характеристикой команды служит ее длина, которая складывается из длины поля кода операции и суммы длин адресных полей:
где n – количество адресных полей в команде.
Максимальное количество операций, которое может быть закодировано в поле кода операций длиной nкоп, составляет
Тогда по известному количеству команд ( K ), составляющих систему команд данной ЭВМ, можно определить необходимую длину поля операции:
Естественно, что эта величина должна быть минимально возможным целым числом. Так, для ЭВМ, имеющей систему команд из 100 команд, длина поля кода операции составит 7 бит.
Если поле адреса команды содержит просто номер ячейки ЗУ, к которой производится обращение, то длина этого поля определяется следующим образом:
где VЗУ – объем запоминающего устройства.
Правомерна и другая постановка задачи – определение максимального объема запоминающего устройства ( VЗУmax ), к которому можно обратиться при заданной длине поля адреса. В этом случае
Современные ЭВМ имеют, как правило, запоминающие устройства с минимальной адресуемой единицей 1 байт ( 1 байт = 8 бит ). Поэтому, например, адресация ЗУ объемом 1 мегабайт ( 1М байт = 2 20 байт ) требует 20 разрядов адресного поля, а поле адреса длиной 16 разрядов позволяет обращаться к памяти максимального объема 64 килобайта ( 1К байт = 2 10 байт ).
Одним из способов уменьшения длины поля адреса является введение в состав ЭВМ дополнительно специального блока памяти небольшого объема – регистровой памяти ( РП ). Это запоминающее устройство имеет высокое быстродействие и служит для хранения часто используемой информации: промежуточных результатов вычислений, счетчиков циклов, составляющих адреса при некоторых режимах адресации и т.д.. Так как объем РП невелик, адресация ее элементов требует относительно короткого адресного поля. Например, для регистровой памяти объемом 8 регистров требуется всего лишь трехразрядное адресное поле.
Команды и адресация в микропроцессоре: форматы, структура, схемы
Основные понятия.
Входное воздействие в виде двоичного кода, предназначенное для управления микропроцессором, называется командой. Ее главная функция — выполнение операций над данными. Команда предписывает шаги по реализации микропроцессором заданной операции, представляющей собой функционально завершенное действие, которое определяется типом используемых данных, источником их получения, операцией над ними, приемником размещения результата, источником получения следующей команды. Машинное представление команды в памяти, состоящее из ряда нулей и единиц, называется объектным кодом команды. Для лучшего восприятия команды используется ее символическое обозначение или мнемокод.
Каждая команда должна содержать сведения, необходимые для ее выполнения. Сведения кодируются. Для кодировки каждой группы сведений выделяется свое поле. Совокупность полей, содержащих необходимые сведения для выполнения требуемой операции, называют форматом команды. В формате команды должны быть определены:
● функциональное назначение операции в виде кода операции;
● адреса источников данных. В общем случае должны быть указаны адреса двух операндов;
● адрес места расположения результата;
● адрес следующей команды.
Способы уменьшения формата команды.
Рассмотрим гипотетическую ситуацию. Допустим, что в формате команды:
● поле кода операций (КО) занимает 4 разряда, что позволяет закодировать 2 4 = 16 операций;
● под адреса двух операндов–источников, адрес места расположения результата, адрес следующей команды выделены поля А O 1, А O 2, АР, АСК (рис. 2.7.1) по 12 разрядов, что позволяет в каждом случае адресовать 2 12 = 4К ячеек памяти.
Как видно из рис. 2.7.1, несмотря на скромные возможности команды, ее общая длина составляет достаточно большое число (52) бит. Для сокращения количества разрядов команды часть информации должна быть задана неявно и не должна зависеть от особенностей конкретной команды. 
Наиболее употребительными являются следующие способы сокращения длины кода команды:
● использование специально предусмотренных для адресации регистров: программного счетчика, указателя стека и др. Например, при выполнении команд с последовательно возрастающими адресами программный счетчик автоматически считывает из памяти следующую команду. В этом случае в формате команды отсутствует поле адреса следующей команды;
● использование неявных способов адресации. Например, при использовании неявной регистровой адресации адрес следующей команды или операнда хранится в регистре, код которого содержит значительно меньшее число разрядов, чем код исполнительного адреса;
● совмещение источника одного из операндов с приемником результата. В этом случае в формате команды исключается поле адреса результата;
● использование команд с укороченной адресацией, т. е. части адресного пространства памяти;
● использование для некоторой группы операций одного регистра. Наиболее часто для этой цели используется аккумулятор. В операциях с аккумулятором не требуется его кодировка. Например, команда ADD
В выполняет операцию сложение содержимого регистра В с аккумулятором А и в него же помещает результат. Такая команда является одноадресной. Ее формат состоит из двух полей: кода операции и адреса операнда. Однако одноадресные команды требуют дополнительных команд для предварительной загрузки операндов в аккумулятор и последующего размещения результатов в памяти;
● использование нескольких аккумуляторов (Motorola 6800, National РАСЕ, Signetic 2650). В этом случае каждая команда имеет два адреса, однако адрес источника и места назначения может быть задан другим аккумулятором. Следует отметить, что в одних процессорах все команды имеют одинаковую длину, в других — разную длину. Одинаковая длина всех команд упрощает декодирование, однако требует большего пространства, поскольку все команды должны быть такой же длины, как самая длинная. Команды могут быть короче слова, равными слову или длиннее слова. В процессорах с неймановской архитектурой команды и данные имеют одинаковую длину и поступают в процессор по шине данных. Поэтому для отличия команд отданных в процессоре предусмотрены средства, обеспечивающие:
● засылку команд (первого байта) в регистр команд с дальнейшей их дешифрацией для активизации устройства управления;
● поступление данных (последующих байт) в аккумулятор или другие регистры для обработки в АЛУ.
Форматы команд некоторых процессоров.
Рассмотрим в общих чертах форматы команд 8–разрядного (8080) и 16–разрядного (8086) процессоров. Длина команды кратна байту и может составлять один, два и более байт.
Достаточно простые форматы имеют команды процессора 8080 (рис. 2.7.2). Длина команд составляет от 1 до 3 байт. Код операции всегда размещается в первом байте команды. Второй и третий байты отводятся под непосредственные данные, адрес порта или ячейки памяти. В командах допускается явное задание только одного адреса памяти. Поэтому система команд процессора 8080 относится к классу одноадресных.
На рис. 2.7.3 изображены форматы команд процессора 8086. Длина команд составляет от 1 до 6 байт.
«В одной корзине»: Немного о хранении кода
Эффективное хранение данных интересует абсолютно всех, кто хоть как-то связан с ИТ. Мы в IaaS-провайдере 1cloud постоянно анализируем опыт коллег — совсем недавно мы обсуждали, как хранят свои данные крупные компании.
Сегодня мы продолжим эту тему и обсудим, как лучше хранить свой код: в одном репозитории или в нескольких. Также мы взглянем на два примера, которые продемонстрируют особенности обоих подходов.
/ фото Dennis Skley CC
Нужно ли сохранять свои исходники в едином, монолитном репозитории или же надо разбить код на блоки и записать их в несколько разных хранилищ? Как правило, это зависит от команды и проекта, над которым она работает. Для начала рассмотрим преимущества и недостатки обоих типов хранения.
Монолитный репозиторий
Обычно первое, что приходит на ум, – это записать весь код в одно хранилище, по крайней мере, на первом этапе: с этого начинает большинство проектов. Репозиторий называют монолитным, если в нем хранится два и более отдельных проекта. Эти проекты слабо или совсем не связаны, а сам репозиторий содержит чересчур много файлов, коммитов и других объектов.
Главное преимущество хранения кода в едином репозитории заключается в том, что так гораздо проще организовать совместную работу с кодом. Мы можем создать один общий проект, состоящий из нескольких подпроектов, а затем связать эти подпроекты, как нам удобно.
Если разработчику нужно изменить код или принцип связи между частями проекта, легче это сделать, когда у него есть доступ к коду всего проекта. Предположим, мы пишем систему для онлайн-торговли, которая строится на микросервисной архитектуре. Когда мы пишем код для сервиса корзины и нам нужно просмотреть или изменить общую библиотеку, мы сразу можем к ней перейти: нам не нужно открывать другой проект или репозиторий. Раз мы можем редактировать зависимости, значит, можем быстрее проводить глобальные изменения, не заботясь об управлении версиями.
Когда весь код хранится в одном месте, нам остается лишь запустить процесс и, например, следить, как изменения в общей библиотеке влияют на работу с корзиной. Объекты доступны в любое время из любого места, изменения проходят быстро и безболезненно. Но не все так гладко.
Зачастую руководители выбирают единый репозиторий просто потому, что с ним будет проще, и они якобы знают, что делают. Из-за подобных решений учащаются случаи, когда разработчики вносят изменения в те части кода, к которым им не следовало бы прикасаться. И это легко сделать, если у вас есть доступ ко всему коду, а у проекта нет явно очерченных границ.
Много проблем возникает при развертывании и масштабировании. Таким образом, теряется целостность системы. Чем больше объем репозитория, тем медленнее будет осуществляться проверка. Если же код хранится в нескольких репозиториях, процесс можно распараллелить, а ошибки, возникающие в одной из частей проекта, не смогут обрушить работу всех сервисов.
Вывод: Если у вас небольшая команда или вы не собираетесь расширяться, логичнее хранить весь код в одном месте. Использовать единый репозиторий удобно и в том случае, если вы не работаете с микросервисами, а разрабатываете монолитное приложение.
Несколько советов по смягчению недостатков монолитных репозиториев в Git (большие размеры файлов, количество коммитов и указателей) здесь предлагает пользователь Хабра.
Хранение кода в нескольких репозиториях
Часть проблем, возникающих при наличии единого репозитория, решается введением нескольких хранилищ. Если говорить о микросервисах, то в идеале для каждого сервиса должен быть свой репозиторий. Этот подход облегчает процесс контроля версий: внесли изменения в библиотеке – обновили ее версию, подправили код сервиса – обновили его версию.
Наличие нескольких репозиториев вынуждает писать код так, как если бы его собирались просматривать сторонние разработчики (что, кстати, вполне вероятно). Вместо того, чтобы думать о правках в коде как о масштабном изменении всей программы, разработчик начинает размышлять, как изменить один модуль, не затрагивая работу всей системы. В итоге связанность между модулями ослабевает.
Это позволяет развертывать их независимо друг от друга. Если наш сервис оформления заказов работает с обеими версиями протокола, мы можем развернуть его еще до того, как будет исправлен код корзины. Такой подход требует наличия высокого уровня дисциплины.
Вывод: Если ваша команда достаточно опытная, чтобы поддерживать регулярное обновление версий и работать с микросервисами, или в ней много человек, которые организованы в небольшие группы, то хранить код лучше в нескольких репозиториях. Подход будет также полезен при обучении новых сотрудников, которые станут более дисциплинированными, если будут следовать правилам обновления версий и сохранять границы между сервисами.
Как хранят код Google и Kiln
Судя по сделанным выводам, большинство компаний, особенно крупных, предпочло бы работать с несколькими репозиториями. Даже если это так, из этого правила есть как минимум одно большое исключение. Как ни странно, десятки тысяч разработчиков Google сегодня используют монолитный репозиторий, где хранится около двух миллиардов строк кода. Чтобы сохранить такие масштабы, Google пришлось разработать систему контроля версий, более известную как Piper.
Доступ к Piper организован с помощью системы Clients in the Cloud (CitC), состоящей из облачного хранилища и файловой системы FUSE для Linux. У каждого разработчика есть рабочая среда, в которой хранятся измененные им файлы. Все записанные файлы хранятся в CitC в виде снэпшотов, что позволяет при необходимости «откатить» работу на несколько этапов назад.
Встроенный в CitC инструмент для поиска кода CodeSearch позволяет вносить мелкие исправления в код, а также передавать измененный код на проверку с возможностью автокоммита: если проверка пройдена, проводится тест, после которого система сама выставляет коммит.
Основу модели монолитного репозитория составляет подход, имеющий название trunk-based development («стволовая разработка»). Основная (trunk) линия представляет собой последнюю версию кода, изменения в которую вносятся разово и последовательно. Сразу после коммита новая версия кода доступна всем пользователям Piper, то есть, по сути, у разработчика перед глазами всегда свежая версия кода.
Что касается добавления функционала, то и старый, и новый код существуют параллельно друг другу, а их использование контролируется с помощью конфигурационных флагов. Этот подход позволяет избегать проблем, которые возникают из-за слияния изменений.
Пользователи Stack Overflow советуют хранить код в едином репозитории, даже когда есть возможность разбить его на несколько хранилищ. Для этого существуют такие инструменты, как подмодули в Git, внешние объекты в Subversion и субрепозитории в Mercurial.
Все они предназначены для построения внутренней иерархии большого проекта, и их можно использовать для выделения отдельных модулей: достаточно каждый проект поместить в отдельный репозиторий, а затем использовать подмодули для включения нужных проектов на определенном уровне иерархии.
Кроме того, в Git есть возможность создавать независимые ветви, которые называют сиротскими (orphan). Они не имеют ничего общего друг с другом и сохраняют исключительно свою историю. Так создается новая сиротская ветвь:
Каждый отдельный проект можно представить отдельной сиротской веткой. По какой-то причине в Git нужно проводить такую очистку после создания этой ветви:
Перед очисткой убедитесь, что выставлен соответствующий коммит. После нее веткой можно смело ею пользоваться.
Другой вариант – создать несколько репозиториев и закинуть эти ветки в каждый из них (имена репозиториев не должны совпадать):
Другого мнения о хранении кода придерживаются разработчики Kiln, в свое время перешедшие с монолитного репозитория Subversion на мультирепозиторий Mercurial. Их проект разделен на пять частей: exe-клиенты, сервер для взаимодействия клиентов (Reflector), сайт, биллинговая система и библиотека Aadvark.
Для каждой части они создали по два репозитория – devel и stable. В первый попадают новые фичи, которые спустя время переходят во второй, а исправленные баги, наоборот, сначала помещаются в stable, а затем как новые функции возвращаются в devel. Для синхронизации используются теги. В Mercurial они представляют собой метаданные репозитория.
Например, чтобы развернуть новую версию сайта, берутся репозитории website-stable и aadvark-stable. К каждому прикрепляется тег, допустим, Website-000123. Затем запускается процесс сбора билда, который клонирует оба репозитория с сервера в директорию сборки и выполняет команду hg up –C Website-000123 для переключения локальной копии на нужный тег. После сбора билда производится развертывание.
Заключение
К выбору того, где и как хранить код, следует подходить осмысленно, а это требует определенных усилий. Нельзя сказать, что один подход однозначно лучше другого. Нужно учитывать состав команды, ваш опыт и стоящие перед вами цели, и уже на основе этого принимать решение. Тем более, при желании всегда можно перейти от одного репозитория к нескольким, и наоборот.
Так или иначе, любое понимание приходит с опытом. Иногда полезно набить шишек, чтобы потом знать, чего стоит опасаться и какие способы наверняка сработают. Поэтому по-настоящему понять, что больше подходит вашей команде, поможет время и желание каждого внести максимальный вклад в развитие продукта.