我應該如何使用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/中刪除未提供給客戶的功能。

只要您在一個方向上對主項目中的所有更改進行操作，此策略就可以正常工作：在主分支上應用它們，然後將主分支合併到客戶分支中。

功能上的變化通常首先應用於一個客戶分支，並且在他們驗證之後，他們可以移植到主分支並從那裏移動到其他客戶的分支。

從客戶分支移植到主分支的功能更改無法通過合併完成，因爲通常以不同方式爲每個客戶定製功能。您可能需要僅向主分支申請幾個提交（包含修復或功能改進），並且您可以使用櫻桃選擇來執行此操作。通常可以使用合併將主要分支中的功能更改移植到客戶分支，因爲主分支應該只包含通用代碼，而不是自定義。