Структура ветки Git для клиента и сервера

Question

Для одного из моих классов CS я и группа пишем приложение, используя архитектуру клиент / сервер.Мне было любопытно, каковы наилучшие методы организации проекта в хранилище Git.Я имею в виду, должны ли мы структурировать каталоги следующим образом:

ProjectDir/
    Clients/
        Client1/
            # files...
        Client2/
            # files...
    Server/
        files....

и отслеживать все в одной и той же ветке git, или нам следует создавать отдельные ветви для клиентов и сервера, например:

на ветке Server:

Project/
    Server/
        # files...

на ветке Clients:

Project/
    Client1/
        # files...
    Client2/
        # files...

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

Answer 1

Я не уверен, какой у вас опыт, но я слышал один и тот же (похожий) вопрос, который снова и снова задавали люди из центральной VCS, такой как SVN.Принципиальное различие между ветвями между SVN (централизованным) и Git состоит в том, что ветки Git очень легки и просты в сравнении.В конце концов, в Git ветвь - это не что иное, как помеченный коммит (и коммит указывает на коммит, который указывает на коммит, вниз по линии, пока ветви не сойдутся).

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

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

Интересная особенность Git состоит в том, что из-за распределенной природы вы можете поддерживать клиент и сервер в отдельных репозиториях.а затем позже поместите их в тот же репозиторий, что и разные ветки.Не будет никакой разницы, кроме как быть безумным, пытаясь понять.

Answer 2

Я думаю, что вы определенно хотите поддерживать равные возможности для клиентской и серверной библиотек, но есть два способа сделать это:

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

• Два отдельных репозитория, один для клиента и один для кодовой базы сервера. Если вы ожидаете совместного использования большого количества кода между приложениями, это становится более громоздким, хотя, возможно, и более корректным / масштабируемым для очень больших компонентов (тогда вы будете использовать третий репозиторий для кода своей общей библиотеки). Использование субмодулей может сильно помочь здесь.

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

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