我应该如何使用git在这种情况下

Question

我创造了我公司基地PHP项目，到目前为止，它具有用户认证，角色，权限，组等。

我的目标是，为每个项目我们开始复制这个基础项目，并添加客户端所需的功能。有些功能可能会让我们回到基础项目中。

这是我的基本工作流程。我的问题是：我如何使用git作为工具来使这个工作流发生？你可以在高层解释我，还是你有一些链接可以解释如何在这种情况下使用git或类似的？

我的git经验被减少到创建分支，进行我的更改并合并回主控制器，所以我很难弄清楚如何使用git来实现我的目标。

---

更新：我觉得我失去了工作流程的重要组成部分：

目前我按照这个流程的项目：

有主分支，我可以随时部署到生产环境中。每次我开始一个新的sprint（scrum）时，我都会创建一个新的开发分支，并且为每个要添加到此开发分支的新功能创建另一个分支（功能分支）。当我完成每个功能时，我将其分支合并回开发分支（开发分支是我们的分段环境）。在sprint结束时，我将dev分支合并到master分支中。

这个工作流程适用于我，我想保留它用于我使用这个基本应用程序的项目。

假设我在这个基本应用程序中发现了一个bug，因此每个使用它的项目都会有相同的错误。我也希望能够将修补程序应用于所有项目。

感谢您的帮助

Answer 1

由于这里的其他答案已经使用子模块的建议，我会尝试使用不同的策略，并用树枝代替。如果您刚开始使用git，并且不想使用子模块，则此方法更容易。此方法还假定您的项目只有一个分支。可以使用多个分支，但很难跟踪这些变化。

初始化一个新的项目，并添加基地项目作为一个遥远：

git remote add base <url> 

这里，基础是你分配到远程名。 现在，创建一个新的跟踪分支，代表你的基地分支：

git branch --track base-project base/master 

有了这个，你就可以升级基地分支时，其通过有人在远程回购其他更新。

接下来，您需要签出master并更新它，以便它包含base-project分支中的所有提交。

git checkout master 
git rebase base-project 

有了这个，您就可以开始在您的基础项目之上开始构建。如果您还有一些需要基础项目的更改，可以使用cherry-pick命令单独选择特定的提交并将其添加到基础项目分支。确保你的工作树是干净的，你HEAD指向基地项目：

git cherry-pick <commit-hash> 

如果你想申请由主引入的所有变化：

git cherry-pick ^HEAD master 

，然后按下分支到远程库：

git push base base-project 

Answer 2

我的问题是：我怎么可以使用git作为一种工具来使这个工作流程发生的呢？

您应该使用子模块。 “子模块”是一个简单的Git项目内的另一个有项目，你可以把它看作一个依赖经理的git的（但不是真的）

你只需要在你的根文件夹，然后添加子模块的文件夹，其将成为所有其他项目共享的共同项目。

git submodule add <url> 

现在，当您克隆项目，你只需要初始化和更新子模块

添加&提交.gitsubmodule文件，并在每个项目中使用这样的：

git submodule init 
git submodule update 

这将取来自每个子模块上游的最新更改，

如果在任何给定时间您决定删除子模块， l回答如何做到这一点。
What is the current way to remove a git submodule?

---

Answer 3

我的目标是，我们每次启动的项目，我们复制这个基地项目，只是添加的功能REQ由客户使用。有些功能可能会让我们回到基础项目中。

最好的解决方案取决于基础项目和附加功能之间的耦合。

如果您的项目设计时考虑了松耦合，并且增加的功能是独立的模块，可以在不影响项目其余部分的情况下安全地添加或移除，那么您可以将每个功能放在Git子模块中，或者甚至将它们作为单独的组件（独立项目）创建并使用Composer将它们加载到主项目中。

对于这两种方法，每个功能都将保留在其自己的Git存储库中。

每个客户将获得基础项目，自定义的composer.json（及其相应的composer.lock）文件和一些自定义的配置文件。

特定于每个客户的文件可以存储在主项目的不同分支中，也可以存储在专用目录（无客户分支）的子目录中。他们需要通过部署脚本（或能够为客户准备软件包的脚本）从那里复制（其他客户的配置被移除）。

这种方法的优点和缺点：

• （+）有每个功能的代码的一个副本;通过在使用该功能的所有客户的目录上运行composer update，可以轻松地将一项功能上执行的更改，修复和改进转移给所有客户;
• （ - ）它不允许一个功能为两个不同的客户独立演变;为了做到这一点，功能项目必须重复。

---

在另一方面，如果耦合紧密，功能不能被提取出来作为独立的子项目（它们都依赖于主体工程仍然），那么我会放置每个特性都以它自己的子目录（全部位于features/目录中）。

主分支（master或develop或任何您使用的名称约定）包含全功能项目（主项目和所有功能）。为每个客户创建一个从主分支开始的新分支。这个客户的所有变化都发生在这个分支上。首先从features/中删除未提供给客户的功能。

只要您在一个方向上对主项目中的所有更改进行操作，此策略就可以正常工作：在主分支上应用它们，然后将主分支合并到客户分支中。

功能上的变化通常首先应用于一个客户分支，并且在他们验证之后，他们可以移植到主分支并从那里移动到其他客户的分支。

从客户分支移植到主分支的功能更改无法通过合并完成，因为通常以不同方式为每个客户定制功能。您可能需要仅向主分支申请几个提交（包含修复或功能改进），并且您可以使用樱桃选择来执行此操作。通常可以使用合并将主要分支中的功能更改移植到客户分支，因为主分支应该只包含通用代码，而不是自定义。