Question

我有一个网站，我保持git。它是一个asp.net webforms网站（但这可能对这个问题不重要）。

该网站由我们的客户用于2个（未来4个）网站。大多数功能都是共享的。但是web.config和css文件夹等一些东西对于每个网站都是唯一的。

以下是代码的简化版本

|--BackOffice
|  \--UI
|--BackOffice.UI
|  \--WebControls
|--BackOfficeTests
|--Deployment
|  \--db
|--BusinessLogicLayer
|  |--bin
|  |--obj
|  \--Properties
|--scripts
|--Website
|  |--admin
|  |--App_Browsers
|  |--App_Code
|  |--App_Data
|  |--Styles
|  |--web.config

Git的优秀结构是什么？

例如，BackOffice代码将完全共享。除了Styles文件夹和web.config文件之外，将共享该网站。

对于一个不会使合并和分支太长发的结构，你有一个很好的建议吗？

我试图建立一个这样的结构：

Master
|--Site1
|--Site2

但是，在将代码从一个分支移动到另一个分支时，我预计会有太多的挑剔子模块是否可以或者会使事情复杂化？

编辑：我真正的大问题是我想直接从我的git repo部署。如果我留在这些目录/文件中，它们将在合并期间合并，除非我做一些复杂的事情（然后我不能让团队中的每个人都这样做）。或者我将不得不忽略这些文件并从其他地方获取它们......

Answer 1

假设您的主分支包含整个项目：

|--BackOffice
|  \--UI
|--BackOffice.UI
|  \--WebControls
|--BackOfficeTests
|--Deployment
|  \--db
|--BusinessLogicLayer
|  |--bin
|  |--obj
|  \--Properties
|--scripts
|--Website
|  |--admin
|  |--App_Browsers
|  |--App_Code
|  |--App_Data
|  |--Styles
|  |--web.config

现在，所有网站共有的任何更改都会提交给此分支。

为各种网站制作单独的分支机构。例如：

来自主分支，

git checkout -b site1
git checkout -b site2
git checkout -b site3
git checkout -b site4

现在，只要您想要更改任何特定于站点的文件，即Styles文件夹或web.config，就可以在这些分支中进行。

现在是部署部分。假设您要部署site1，在基于master的本地系统上创建临时分支，将site1分支合并到其中并进行部署。最后删除临时分支。

git checkout -b temp
git merge site1

tar或压缩您的代码并进行部署。之后，

git checkout master
git branch -D temp

如果您不希望公开部署方式，您甚至可以制作一个小型shell脚本。让我们调用此脚本 deploy.sh 例如：

#!/bin/bash

if [ ! $1 ]; then
        echo "Please pass in the name of the site you want to deploy."
        exit 1
fi

#Check if we are on master branch
git status | grep "On branch master"
if [ $? -ne 0 ]; then
        echo "You are not on master. Please execute 'git checkout master'"
        exit 1
fi

#Check if the entered site for deployment actually exists
git branch | grep $1 || { echo "No branch $1 exists for deployment."; exit 1; }

#Update from remote
git checkout -b temp
git merge $1
tar -cvf deploy-$1.tar ./deploy.sh *
[ $? -ne 0 ] && echo "Some problem archiving the files..." && exit 1
git checkout master
git branch -D temp

echo "Please use deploy-$1.tar file to deploy the site. Thanks."

exit 0

现在当你说./deploy.sh site2时，这个脚本将在幕后完成所有脏工作，并为您提供一个可以在生产服务器上部署的tar文件。

我希望这有用......

Answer 2

对于共享的BackOffice代码，submodule是一个很好的解决方案，每个站点都充当父回购。

但这并没有解决配置文件。

对于那些，一种可能性是content filter，但这将涉及为不同的客户存储和推送变量的值。

最好将这些配置文件保存在客户特定分支中的父仓库中。

Answer 3

我可能会制作单独的“Site”和“Common”目录，其中“Common”包含战略要点的符号链接以及一个或两个子模块，如下所示：

 Project
 |==.git
 |--Site
 |  |--.git
 |  \--Website
 |     |--Styles
 |     \--web.config
 \--Common
    |--.git
    |--BackOffice
    |  \--UI
    |--BackOffice.UI
    |  \--WebControls
    |--BackOfficeTests
    |--Deployment
    |  \--db
    |--BusinessLogicLayer
    |  |--bin
    |  |--obj
    |  \--Properties
    |--scripts
    \--Website
       |--admin
       |--App_Browsers
       |--App_Code
       |--App_Data
       |--Styles -> ../../Site/Website/Styles
       \--web.config -> ../../Site/Website/web.config

这不是唯一可以提供服务的布局 - 例如，如果应该很容易让不同的网站挑选并选择要调整的内容，您可以保留当前的布局，添加“公共”子项目并将您使用的任何内容符号化没改变，就像这样：

 Site
 |==.git
 |--BackOffice -> Common/BackOffice
 |--BackOffice.UI -> Common/BackOffice.UI
 |--BackOfficeTests -> Common/BackOfficeTests
 |  [...]
 |--Website
 |  |--admin -> ../Common/Website/admin
 |  |--App_Browsers -> ../Common/Website/App_Browsers
 |  [...]
 |  |--Styles
 |  \--web.config
 \--Common
    |--.git
    |--BackOffice
    |  \--UI
    |--BackOffice.UI
    |  \--WebControls
    |--BackOfficeTests
    |--Deployment
    |  \--db
    |--BusinessLogicLayer
    |  |--bin
    |  |--obj
    |  \--Properties
    |--scripts
    \--Website
       |--admin
       |--App_Browsers
       |--App_Code
       |--App_Data
       |--Styles.example
       \--web.config.example

我看的越多，我越喜欢最后一个。

具有多个网站的git中的结构

3 个答案: