一種協作方式git是讓每個開發人員擁有自己的分支（
我（開發人員 1）想到了以下命令周期，從Developer-1分支開始（故意避免git pull）：
1. $ (Developer-1) git fetch --all
2. $ (Developer-1) git merge origin/Developer-1
3. $ (Developer-1) git merge origin/dev
4. Do some work on `Developer-1` over time, during which it is likely that other devs push to remote
5. $ (Developer-1) git fetch --all
6. $ (Developer-1) git merge origin/Developer-1
7. $ (Developer-1) git merge origin/dev
8. $ (Developer-1) git push Developer-1:Developer-1
9. $ (Developer-1) git push Developer-1:dev
10. Restart cycle from (1)
這是一個較短的版本，使用git pullgit 的內置名稱決議（以防對其他人有幫助）：
1. $ (Developer-1) git pull
2. $ (Developer-1) git merge origin/dev
3. Do some work on `Developer-1` over time, during which it is likely that other devs push to remote
4. $ (Developer-1) git pull
5. $ (Developer-1) git merge origin/dev
6. $ (Developer-1) git push Developer-1:Developer-1
7. $ (Developer-1) git push Developer-1:dev
8. Restart cycle from (1)
當我想測驗dev分支時：
1. $ (Developer-1) git switch dev
2. $ (dev) git fetch --all
3. $ (dev) git merge origin/dev
當我想推動生產時：
1. $ (dev) git switch master
2. $ (master) git fetch --all
3. $ (master) git merge origin/dev
2. $ (master) git push master:master
資源
- 這里的作業流程4，和上面一樣
- git book 中的分布式作業流章節也說明了集中式作業流，但不完全是上面的方法
問題
- 我的命令回圈是實作上述作業流程的正確方法嗎？
- 當您有一個擁有集中式存盤庫的小團隊時，上述作業流程是一種常見的協作方式嗎？
uj5u.com熱心網友回復：
如果您在網路上搜索“git 作業流”，您會發現數十甚至可能數百篇討論特定作業流、它們的優缺點以及如何實作它們的詳細資訊的文章。
不過，有一個常見的建議：在 git 中，分支很便宜：大多數作業流程涉及每周創建和洗掉多個分支，可能一天幾個。git 中的實際歷史機制都是基于commits的，分支也很方便，而且大多是臨時的標簽。
如果您將自己限制為每個開發人員一個分支，那么您不能在測驗或審查代碼時不合并分支，或者暫停作業以處理更高優先級的作業；如果他們生病或休假，你不能接手別人的任務。這就是為什么您通常會看到使用分支來表示單個作業單元的作業流。
將這些分支視為特定開發人員“擁有”可能會有一些優勢，這樣他們就可以自由地重寫歷史記錄（修改提交、重新定位到新的起點等）。
在您提議的作業流程中另一件不尋常的事情（盡管并非嚴格意義上的“錯誤”，因為它會導致可用的歷史記錄）是您將開發人員分支直接推送到“開發”。更常見的是切換到“dev”，將開發人員（或任務）分支合并到其中，然后推送結果。
我建議您閱讀的另一件事是 Gitlab、Bitbucket、Github 或 Gerrit 等中央工具的優勢，它們促進和強制執行代碼的同行評審，而不是讓所有用戶直接推送到主要的長期運行的分支。合并到“dev”然后發生在服務器上，由審查工具控制，開發人員只需要在他們自己的分支上作業。
uj5u.com熱心網友回復：
下面是有問題的作業流的更類似于 git 的實作。它不會從一個本地分支推送到具有不同名稱的遠程分支。
希望對其他人也有幫助。
1. $ (Developer-1) git pull #merge in remote changes to current branch (in case developer moved between computers). Most likely FF merge.
2. Do some work on `Developer-1` branch over time, during which it is likely that other devs push to remote
3. $ (Developer-1) git push
4. $ (Developer-1) git switch dev
5. $ (dev) git pull #merge in remote changes to current branch.
6. $ (dev) git merge Developer-1 #merge in local branch Developer-1 into local branch dev.
7. $ (dev) git push #push the newly updated dev branch to remote
8. $ (dev) git branch -f Developer-1 #move local Developer-1 branch pointer from the pre-merge commit, to wherever dev now points to (which will be a new merge commit if a "true merge" happened).
9. $ (dev) git switch Developer-1
10. $ (Developer-1) git push
11. Restart from 1
結果
- Developer-1 已更新并推送到遠程
- dev 接收來自 Developer-1 的更改
- dev 被推送到遠程
- Developer-1 指標移至 dev。這是使此作業流程正常運行的重要步驟。由于 Developer-1 已合并到 dev 中，因此移動 Developer-1 指標不會導致與遠程服務器上的 Developer-1 發生任何沖突。它只會領先于其遠程版本，因此下次推送 Developer-1 時會更新遠程版本。
- 換句話說，如果你不小心嘗試從遠程的 Developer-1 拉到本地的 Developer-1，在移動指標之后，你只會被告知 Developer-1 是最新的。同樣，因為遠程版本現在是提交鏈中本地副本的祖先。
- 如果您沒有先將遠程的更改合并到本地分支，那么知道 git 將不允許您將任何內容推送到遠程也很好。因此，您不必擔心在推送之前忘記上面的拉取命令之一。Git 將使您保持一致并避免錯誤。
選擇
正如@torek 在對另一個答案的評論中指出的那樣，與 ff-only 合并與僅移動指標相同。所以這也有效：
1. $ (Developer-1) git pull #merge in remote changes to current branch (in case developer moved between computers). Most likely FF merge.
2. Do some work on `Developer-1` branch over time, during which it is likely that other devs push to remote
3. $ (Developer-1) git push
4. $ (Developer-1) git switch dev
5. $ (dev) git pull #merge in remote changes to current branch.
6. $ (dev) git merge Developer-1 #merge in local branch Developer-1 into local branch dev.
7. $ (dev) git push #push the newly updated dev branch to remote
8. $ (dev) git switch Developer-1
9. $ (Developer-1) git merge dev --ff-only #merge dev branch back into Developer-1 branch, via ff-only (flag should not be needed, but just in case)
10. $ (Developer-1) git push
11. Restart from 1
uj5u.com熱心網友回復：
我今天脾氣暴躁，這可能讓我持憤世嫉俗的觀點，即前4 個描述的 GitLab 作業流程實際上都是相同的。
-
集中式作業流程涉及每個貢獻者提交到主分支而不使用任何其他分支。
我當地的分公司叫做
main. -
開發人員不是直接提交到主分支，而是創建一個分支，進行更改，然后將其合并到主分支中。
我的本地分支名為
feat/my-feature. -
基于主干的開發有助于在稱為主干的單個分支上進行并發開發。
我的本地分支名為
trunk. 為簡單起見，我們只呼叫它main，然后這顯然變成了#1。 -
個人分支類似于功能分支，但不是每個功能都有一個分支，而是每個開發人員。
我當地的分公司叫做
user/TTT/my-feature.
因此，實際上，這些作業流程中的唯一區別是您所稱的本地分支。無論作業流程如何，使用最新版本的遠程更新本地分支的方式main以及推送方式都可以相同！
例如，無論您在上面使用哪個作業流程，要使用 upstream 更新您的本地分支main，您都可以：
# if you prefer rebase (my personal preference most of the time)
git pull --rebase origin main
# or
git fetch
git rebase origin/main
# if you prefer merge
git pull origin main
# or
git fetch
git merge origin/main
當是時候推動：
# No code review
git push origin <local-branch-name>:main
# Using a code review
git push origin <local-branch-name> # and then create a PR/MR into main
筆記：
- 根據您的本地分支是否正在跟蹤遠程，可以使用其中一些命令的較短版本。例如，如果您不使用代碼審查，那么您的本地功能分支可能會設定為 track
origin/main，在這種情況下git pull，git push可以在不指定其他分支名稱的情況下使用。如果您使用代碼審查，您通常更愿意跟蹤與本地分支同名的上游分支，以避免混淆。 - 分支只是指向提交的指標。只需重命名本地分支，您就可以隨時更改為這 4 個作業流程中的任何一個。
- 多個功能分支 (#2) 和單個個人分支名稱 (#4) 之間的區別是毫無意義的區別。如果您一次只處理一件事，并且始終使用相同的分支名稱，那么將其稱為功能分支或個人分支都沒有關系。如果您一次處理不止一件事情，那么您是否有多個功能分支或多個個人分支，或多個存盤，或在您的存盤庫之外保存多個作業副本都無關緊要，在這方面這樣做會更改您正在使用的作業流程的名稱。
結論：所有這些作業流程基本相同，您建議的作業流程是一種常用的協作方式，無需在遠程端進行代碼審查。（也許您正在結對編程或者只是不需要代碼審查。）至于添加第二個共享分支以便您同時擁有dev和master分支，如果您希望跟蹤指示的歷史版本，這也很常見通過合并dev到master. 不過，在您的情況下，有些人不會理會master分支，而只會標記dev已發布到生產環境的提交，當它發生時。本質上是一樣的。我個人喜歡有一個分支來指示生產中的內容，這樣更容易從 進行修補程式master，而不是從 "dev”。
旁注：在我的公司，我們曾經命名我們所有的分支機構，feat/12345-my-cool-feature（聽起來像作業流＃2）但后來轉移到user/first.name/12345-my-cool-feature（聽起來像作業流＃4）。（我們不限制您可以創建多少個分支。）我們要求人們在創建分支時使用他們的名字的原因很簡單，因此當我們查看遠程分支時，我們知道是誰創建了它們和/或當它們變得陳舊時與誰交談。（當有人離開公司時特別有用。）它還有一個額外的好處，我們都知道任何以user/*can 為前綴的分支都將被重寫，并且不應該成為新分支的基礎，除非您rebase --onto在分支被重寫時使用起來很舒服.
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/515211.html
標籤：混帐