-
維護(hù)分支hotfix的工作內(nèi)容查看全部
-
release發(fā)布分支的作用查看全部
-
功能分支的使用原則查看全部
-
功能分支的工作流程查看全部
-
Master和developer分支的區(qū)別查看全部
-
git分支流查看全部
-
PHP 項(xiàng)目中g(shù)itflow多人協(xié)作開發(fā)查看全部
-
feature分支 使用規(guī)范： 可以從develop分支發(fā)起feature分支 代碼必須合并回develop分支 feature分支的命名可以使用除master，develop，release-*，hotfix-*之外的任何名稱 feature分支（有時也可以被叫做“topic分支”）通常是在開發(fā)一項(xiàng)新的軟件功能的時候使用，這個分支上的代碼變更最終合并回develop分支或者干脆被拋棄掉（例如實(shí)驗(yàn)性且效果不好的代碼變更）。 一般而言，feature分支代碼可以保存在開發(fā)者自己的代碼庫中而不強(qiáng)制提交到主代碼庫里。查看全部
-
建立新的修復(fù)補(bǔ)丁 除了是計(jì)劃外創(chuàng)建的以外，hotfix分支與release分支十分相似：都可以產(chǎn)生一個新的可供在生產(chǎn)環(huán)境部署的軟件版本。 當(dāng)生產(chǎn)環(huán)境中的軟件遇到了異常情況或者發(fā)現(xiàn)了嚴(yán)重到必須立即修復(fù)的軟件缺陷的時候，就需要從master分支上指定的TAG版本派生hotfix分支來組織代碼的緊急修復(fù)工作。 這樣做的顯而易見的好處是不會打斷正在進(jìn)行的develop分支的開發(fā)工作，能夠讓團(tuán)隊(duì)中負(fù)責(zé)新功能開發(fā)的人與負(fù)責(zé)代碼緊急修復(fù)的人并行的開展工作。查看全部
-
使用規(guī)范： 可以從develop分支派生 必須合并回develop分支和master分支 分支命名慣例：release-*查看全部
-
release分支是為發(fā)布新的產(chǎn)品版本而設(shè)計(jì)的。在這個分支上的代碼允許做小的缺陷修正、準(zhǔn)備發(fā)布版本所需的各項(xiàng)說明信息（版本號、發(fā)布時間、編譯時間等等）。通過在release分支上進(jìn)行這些工作可以讓develop分支空閑出來以接受新的feature分支上的代碼提交，進(jìn)入新的軟件開發(fā)迭代周期。 當(dāng)develop分支上的代碼已經(jīng)包含了所有即將發(fā)布的版本中所計(jì)劃包含的軟件功能，并且已通過所有測試時，我們就可以考慮準(zhǔn)備創(chuàng)建release分支了。而所有在當(dāng)前即將發(fā)布的版本之外的業(yè)務(wù)需求一定要確保不能混到release分支之內(nèi)（避免由此引入一些不可控的系統(tǒng)缺陷）。 成功的派生了release分支，并被賦予版本號之后，develop分支就可以為“下一個版本”服務(wù)了。所謂的“下一個版本”是在當(dāng)前即將發(fā)布的版本之后發(fā)布的版本。版本號的命名可以依據(jù)項(xiàng)目定義的版本號命名規(guī)則進(jìn)行。查看全部
-
功能分支擴(kuò)展。。。。查看全部
-
feature分支 使用規(guī)范： 可以從develop分支發(fā)起feature分支 代碼必須合并回develop分支 feature分支的命名可以使用除master，develop，release-*，hotfix-*之外的任何名稱 feature分支（有時也可以被叫做“topic分支”）通常是在開發(fā)一項(xiàng)新的軟件功能的時候使用，這個分支上的代碼變更最終合并回develop分支或者干脆被拋棄掉（例如實(shí)驗(yàn)性且效果不好的代碼變更）。 一般而言，feature分支代碼可以保存在開發(fā)者自己的代碼庫中而不強(qiáng)制提交到主代碼庫里。查看全部
-
master分支 master分支上存放的應(yīng)該是隨時可供在生產(chǎn)環(huán)境中部署的代碼（Production Ready state）。當(dāng)開發(fā)活動告一段落，產(chǎn)生了一份新的可供部署的代碼時，master分支上的代碼會被更新。同時，每一次更新，最好添加對應(yīng)的版本號標(biāo)簽（TAG）。 develop分支 develop分支是保存當(dāng)前最新開發(fā)成果的分支。通常這個分支上的代碼也是可進(jìn)行每日夜間發(fā)布的代碼（Nightly build）。因此這個分支有時也可以被稱作“integration branch”。 當(dāng)develop分支上的代碼已實(shí)現(xiàn)了軟件需求說明書中所有的功能，通過了所有的測試后，并且代碼已經(jīng)足夠穩(wěn)定時，就可以將所有的開發(fā)成果合并回master分支了。對于master分支上的新提交的代碼建議都打上一個新的版本號標(biāo)簽（TAG），供后續(xù)代碼跟蹤使用。 因此，每次將develop分支上的代碼合并回master分支時，我們都可以認(rèn)為一個新的可供在生產(chǎn)環(huán)境中部署的版本就產(chǎn)生了。通常而言，“僅在發(fā)布新的可供部署的代碼時才更新master分支上的代碼”是推薦所有人都遵守的行為準(zhǔn)則。基于此，理論上說，每當(dāng)有代碼提交到master分支時，我們可以使用Git Hook觸發(fā)軟件自動測試以及生產(chǎn)環(huán)境代碼的自動更新工作。這些自動化操作將有利于減少新代碼發(fā)布之后的一些事務(wù)性工作。查看全部
-
歷史分支 相對使用僅有的一個master分支，Gitflow工作流使用2個分支來記錄項(xiàng)目的歷史。master分支存儲了正式發(fā)布的歷史，而develop分支作為功能的集成分支。這樣也方便master分支上的所有提交分配一個版本號。 功能分支 功能分支 每個新功能位于一個自己的分支，這樣可以push到中央倉庫以備份和協(xié)作。但功能分支不是從master分支上拉出新分支，而是使用develop分支作為父分支。當(dāng)新功能完成時，合并回develop分支。新功能提交應(yīng)該從不直接與master分支交互。查看全部
舉報(bào)
0/150
提交
取消