2012-04-24 40 views
0

我一直在研究Git,並且我瞭解了基本概念,除了它適合小團隊的工作流程。git如何融入您的網絡工作流程?

按我的理解,我想:

  1. 一個共享的半公共回購爲我自己和我的團隊從(拉改變我們的本地副本)和測試功能在工作

  2. 一個回購,我們推動任何經過測試並準備就緒的東西。

  3. 現場回購,其中的工作目錄是實際的網站

我是否理解這個或超過它需要複雜它的根文件夾?試圖圍繞它思考,很少有教程詳細介紹這個主題。

回答

0

我的開發團隊只有一個遠程回購站,所有更改都被推送。

開發中的功能被分支以避免破壞主副本,因此可能同時存在多個活動分支。每個開發人員都有一個實際在開發服務器上運行的「本地」回購(我們傾向於通過SSH使用VIM進行開發)。每個「本地」回購站都被設置爲一個用用戶名稱標記的唯一虛擬主機。因此,在開發服務器上運行的站點可能有三個或四個不同的版本。這使開發人員可以立即測試代碼更改。

在準備發佈時,所有完成的分支都會合並,並將生成的代碼通過git拖至與生產環境非常匹配的預部署服務器。批准後,特定的提交會標記一個版本號,然後使用git或rsynched將其提交到生產服務器,然後再通過幾次測試,以確保部署順利進行。

0

而不是使用多個倉庫的開發/發行/ ......我會用樹枝在一個庫中。

更多的想法有關,一個可能的模式(以及它是如何在一個團隊中使用)可以在這篇博客文章中找到: http://nvie.com/posts/a-successful-git-branching-model/

(不要害怕,在頂部外觀圖複雜的,但如果你只是讀文章變得非常清楚:))


在一個不相關的注意事項:Git是對很多事情非常強大和良好的,但也可以很複雜,使用(包括什麼你會期望一個由內核黑客編寫的版本控制系統; D)。

對於分散式VCS,Bazaar可能是一個很好的選擇。它與git共享重要的想法。但是我已經從許多不同的人那裏反覆聽到,對於那些沒有計算機科學背景並且可能第一次使用版本控制的團隊來說,處理起來要容易得多。

(以防萬一符合您的標準,我不知道您的團隊和人員的背景和經驗範圍在網站開發中相當廣泛,不想在這裏啓動VCS flamewar。)