建站
咨詢
售后
建站咨詢
新聞中心
軟件開發(fā)人員之所以能夠在分布式協(xié)作領(lǐng)域一直扮演著先行者的角色，原因在于他們的工作成果一直以數(shù)字化形態(tài)體現(xiàn)。而隨著網(wǎng)絡(luò)黎明時(shí)代的全面鋪開，他們的工作流程也開始走上聯(lián)網(wǎng)道路。
我們提供的服務(wù)有：成都網(wǎng)站制作、網(wǎng)站建設(shè)、微信公眾號(hào)開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、太原ssl等。為上千余家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的太原網(wǎng)站制作公司
幫助軟件開發(fā)人員實(shí)現(xiàn)協(xié)作的各類工具加上圍繞此類工具所構(gòu)成的文化理念，當(dāng)然也希望能夠融入主流體系當(dāng)中。遙想當(dāng)年，電子郵件與即時(shí)消息——二者同樣是在接觸普通大眾之前，首先由開發(fā)人員廣泛使用——也曾經(jīng)扮演過同樣的角色并面臨類似的狀況。不過時(shí)至今日，這些通信模式早已走入了尋常百姓家。
不過為了協(xié)調(diào)Linux內(nèi)核開發(fā)而誕生的工具Git與圍繞該工具所衍生的文化體系GitHub，目前尚未表現(xiàn)出同樣積極的關(guān)聯(lián)態(tài)勢(shì)。大多數(shù)非開發(fā)人士并不依靠編碼作為謀生手段。但隨著各個(gè)行業(yè)、各個(gè)領(lǐng)域的工作成果與流程逐步走上數(shù)字化方向，很多普通人同樣會(huì)為這些共享式工具所吸引、并借此實(shí)現(xiàn)共享式數(shù)字化成果的協(xié)調(diào)式構(gòu)建。有鑒于此，Git與GitHub才能夠在代碼之外、融入更多工作成果的實(shí)施流程當(dāng)中。
根據(jù)Wired、ReadWrite以及其它多家站點(diǎn)的報(bào)道，GitHub目前已經(jīng)被用于實(shí)現(xiàn)食譜、樂譜、書籍、字體、法律文件、課程與教程以及數(shù)據(jù)集等資源的協(xié)作開發(fā)管理?？紤]到Git本身令人望而生畏的復(fù)雜性，以上狀況無疑有些匪夷所思。
原因之一在于GitHub利用其Web界面逐步提供更多底層Git功能。另一項(xiàng)理由則是，更多Web應(yīng)用程序開始利用GitHub作為其運(yùn)行平臺(tái)。接下來再看文化方面的因素：GitHub帶來了一種特殊的協(xié)作途徑。Dave Winer將其形容為“個(gè)人工作述職”階段。我個(gè)人則用“看得見的工作”進(jìn)行描述。Responsive Organization活動(dòng)為其“隱私之上的透明性”而歡欣鼓舞。在GitHub管理體系內(nèi)部，倡導(dǎo)者Ben Balter也以“開放式協(xié)作”對(duì)其加以盛贊。
在一篇尚未正式發(fā)表的博文中，我讀到了Ben Balter就這一觀點(diǎn)的說明。而自從該博文被托管在公共GitHub庫中之后，我除了查閱文章的草稿之外，還對(duì)審查意見以及圍繞該草稿展開的探討內(nèi)容進(jìn)行了高度關(guān)注。當(dāng)然，單單一套庫并不一定需要向公眾開放——但每一家企業(yè)都應(yīng)當(dāng)鼓勵(lì)將開放協(xié)作機(jī)制引入內(nèi)部業(yè)務(wù)流程。根據(jù)GitHub發(fā)展戰(zhàn)略副總裁Brian Doll的觀點(diǎn)，目前已經(jīng)有越來越多企業(yè)對(duì)這種共享式機(jī)制表現(xiàn)出深厚興趣。
人們常說，時(shí)至今日每一家企業(yè)都可算作是軟件廠商。從抽象角度來看，這種說法并無不可——只要大家將知識(shí)產(chǎn)權(quán)也定義在軟件范疇之內(nèi)。而且對(duì)于不少企業(yè)來說，其真正業(yè)務(wù)價(jià)值也確實(shí)體現(xiàn)在內(nèi)部開發(fā)的軟件成果身上。
企業(yè)始終期望著能夠?qū)⑦@種協(xié)作式發(fā)展機(jī)制在代碼、測試、質(zhì)量保證以及說明文檔等傳統(tǒng)領(lǐng)域之外加以進(jìn)一步拓展。不過如果此類協(xié)作機(jī)制的貢獻(xiàn)成果完全取決于我們自身對(duì)于業(yè)務(wù)或者客戶的理解，那么大家可能很難直接參與進(jìn)去。
“這太瘋狂了，”Brain Doll表示?！叭绻蠹以阢y行中擔(dān)任管理者角色，那么員工及客戶所使用的財(cái)富管理工具也就成為銀行提供的產(chǎn)品——他們?cè)趺纯赡苤苯訁⑴c此類方案的改進(jìn)工作？”但在GitHub的幫助下，每一位股東都能夠成為一流的參與者。相較于僅僅用于記錄系統(tǒng)運(yùn)作狀態(tài)的電子郵件，他們還可以發(fā)送各類請(qǐng)求并直接在系統(tǒng)當(dāng)中討論相關(guān)問題。
馴服Git這只猛獸
作為GitHub引擎蓋之下控制引擎的分布式版本，Git的運(yùn)作方式不僅能夠給非程序員帶來驚喜、更能讓普通程序員們通過集中化系統(tǒng)對(duì)其實(shí)現(xiàn)訪問。
在此類系統(tǒng)當(dāng)中，于庫內(nèi)部創(chuàng)建一套分支可謂非同小可，其作用相當(dāng)于一系列既有成果的備用版本。在Git當(dāng)中，一套分支就相當(dāng)于一套輕量級(jí)構(gòu)建成果、一種通過移動(dòng)指針而非數(shù)據(jù)所產(chǎn)生的嘗試預(yù)期。在傳統(tǒng)系統(tǒng)當(dāng)中，即使僅僅是為了變更文檔中的每個(gè)字句而構(gòu)建的分支都會(huì)帶來高昂的實(shí)現(xiàn)成本。但Git卻讓這種機(jī)動(dòng)性變得物美價(jià)廉。GitHub能夠?qū)⑵淝度氲焦ぷ髁鞒坍?dāng)中——即獲取到的請(qǐng)求——流程會(huì)對(duì)變更內(nèi)容加以封裝，而后將其與文檔的變更歷史相結(jié)合。
Git的這種千變?nèi)f化的能力使其成為工作流程創(chuàng)新領(lǐng)域的理想實(shí)驗(yàn)環(huán)境，但可供選擇的實(shí)現(xiàn)方式過多也帶來了新的復(fù)雜性層。分支與合并機(jī)制雖然足夠強(qiáng)大，但技術(shù)人員仍然在面對(duì)何時(shí)以及如何進(jìn)行分支與合并操作時(shí)分裂成了各種派別。這一切都給程序員提出了嚴(yán)峻挑戰(zhàn)，而且這種挑戰(zhàn)要遠(yuǎn)比其它麻煩更難于解決。有鑒于此，我們?nèi)绾尾拍荞Z服這只猛獸，從而保證非技術(shù)出身的利益相關(guān)者也能享受到它所帶來的便利？
GitHub給出的答案是：強(qiáng)化網(wǎng)站本身以實(shí)現(xiàn)各類核心操作。如果一位律師希望修改法律文件中的個(gè)別字句，她根本不必接觸恐怖的Git客戶端; 她完全能夠通過瀏覽器直接實(shí)現(xiàn)文件編輯。這種操作將啟動(dòng)一項(xiàng)pull request流程，其會(huì)針對(duì)特定變更創(chuàng)建出新的分支。GitHub用戶總愛說“實(shí)現(xiàn)變更只有惟一一種方式。”雖然不是每個(gè)人都必須遵循這種黃金定律，但選擇最簡實(shí)現(xiàn)辦法無疑能大大減少工作中遇到的阻力。
這樣一來，只要企業(yè)愿意接納GitHub、那么每一位員工都能輕松實(shí)現(xiàn)這種最佳實(shí)踐?！安灰诎l(fā)現(xiàn)軟件問題時(shí)盲目指責(zé)水冷機(jī)制不夠給力，”Brain Doll提醒道?！艾F(xiàn)在大家已經(jīng)有辦法對(duì)自己了解范圍內(nèi)的問題加以修正。”這種鼓勵(lì)人們參與進(jìn)來的機(jī)制對(duì)客戶也同樣有效。
GitHub自身的變更同樣至關(guān)重要?！叭绻磺猩韰⑴c進(jìn)來，”Software Carpentry項(xiàng)目創(chuàng)始人Greg Wilson指出，“我根本沒辦法搞清楚GitHub的權(quán)限管理機(jī)制、允許用戶針對(duì)單一repo制作多種fork或者完成其它類似的工作。”
不過無論GitHub風(fēng)格的交互方案如何具體起效，變更機(jī)制都能確切發(fā)揮作用——而無需擔(dān)心針對(duì)單一變更的貢獻(xiàn)內(nèi)容到底屬于代碼、文檔、法律建議、企業(yè)立場抑或是客戶反饋。
作為GitHub當(dāng)中最為重要的創(chuàng)新成果，溝通與共享的核心價(jià)值在引入其它社交媒體中的交流內(nèi)容之后得到了進(jìn)一步增強(qiáng)。舉例來說，大家可以在Twitter上通過提及另一位Twitter用戶的用戶名來引起對(duì)方的注意。這種@提及技術(shù)在GitHub當(dāng)中也同樣為個(gè)人及團(tuán)隊(duì)作出了巨大貢獻(xiàn)。
GitHub Pages同樣不可不提，這項(xiàng)服務(wù)負(fù)責(zé)托管GitHub庫之上的門戶網(wǎng)站。對(duì)于熟悉Git并樂于安裝（并以本地方式使用）基于Ruby的站點(diǎn)生成工具——也就是Jekyll——的技術(shù)型博主來說，GitHub Pages絕對(duì)是他們的心頭最愛。不過也有用戶發(fā)現(xiàn)，我們并不一定需要安裝Jekyll。大家完全可以直接在瀏覽器當(dāng)中管理GitHub Pages，同時(shí)享受版本歷史以及問題討論功能所帶來的便利。
讓變化變得可視化
版本控制與變更可視化機(jī)制已經(jīng)深深植根于軟件開發(fā)領(lǐng)域當(dāng)中。時(shí)至今日，已經(jīng)沒有任何組件開發(fā)人員會(huì)考慮在無法通過“diff”進(jìn)行變更內(nèi)容說明的前提下討論新版本中的某些代碼。
大多數(shù)知識(shí)型員工并不具備這種非對(duì)等性分布預(yù)期。雖然在企業(yè)當(dāng)中這種數(shù)字化技術(shù)認(rèn)知應(yīng)當(dāng)成為基礎(chǔ)性素養(yǎng)，但實(shí)際上其并未真正得到普及。而這也種障礙也同時(shí)影響到文化（‘我們之前從沒采取過這樣的方式’）以及技術(shù)（‘我的工作成果并不是什么文本文件’）層面。
軟件開發(fā)所產(chǎn)生的數(shù)字化成果仍然體現(xiàn)為包含有文本內(nèi)容的文件，而且其實(shí)質(zhì)能夠追溯至原始的打孔卡載體。我們也仍然需要一行一行對(duì)這些文件的內(nèi)容在視覺基礎(chǔ)上進(jìn)行修改。編譯器與IDE能夠從模塊以及方法的角度了解代碼內(nèi)容，但版本控制系統(tǒng)并不會(huì)分享這種認(rèn)知結(jié)果。雖然從理論角度講，利用計(jì)算設(shè)備將變更抽象理解為模塊X或者方法Y、并隨時(shí)間推移持續(xù)觀察此類變更聽起來完全可行，但在現(xiàn)實(shí)當(dāng)中卻并非如此。
這種理論與現(xiàn)實(shí)之間的不匹配狀況源自多種深層次歷史原因，而且在短時(shí)間內(nèi)不可能很快得到扭轉(zhuǎn)。與此同時(shí)，我們可以通過兩種方式解決這一難題——而GitHub恰恰在這兩方面都有所建樹。
方法之一在于將富文檔轉(zhuǎn)換為文本文件。在政府機(jī)構(gòu)當(dāng)中這是一種常見的實(shí)踐方式，其中GitHub則扮演著協(xié)作平臺(tái)的角色，Ben Balter指出。他還創(chuàng)建出一款工具，能夠?qū)⒄畠?nèi)部廣泛使用的Word文檔轉(zhuǎn)化為Markdown——一種能夠在GitHub以及其它多種環(huán)境下使用的純文本格式。這種變通方案還遠(yuǎn)遠(yuǎn)稱不上理想方式，這主要出于兩點(diǎn)原因。其一，對(duì)文檔格式進(jìn)行往來轉(zhuǎn)換通常存在風(fēng)險(xiǎn)——而Markdown并不屬于標(biāo)準(zhǔn)化格式。其二，其中包含多種變量; 事實(shí)上，GitHub所使用的準(zhǔn)確來說應(yīng)該是Git Hub Flavored Markdown。
從理想角度看，GitHub應(yīng)當(dāng)能夠直接處理富文檔格式，其在這方面也確實(shí)取得了一定進(jìn)展。我們長久以來早已能夠以可視化方式對(duì)不同圖像中的差別作出對(duì)比。一年之前，“prose diff”能夠?qū)⒉煌琈arkdown文件內(nèi)HTML渲染內(nèi)容之間的差別以彩色方式進(jìn)行高亮顯示。這種方式同樣也能用于著重體現(xiàn)CSV數(shù)據(jù)以及HTML表間的差異部分，但卻并沒能在文檔結(jié)構(gòu)識(shí)別方面做出更多貢獻(xiàn)。
此類識(shí)別能力如今在一種格式當(dāng)中成為現(xiàn)實(shí)，這就是GeoJSON。它能夠?qū)⒌乩砜臻g信息以JSON格式進(jìn)行編碼，而GItHub除了可以利用其作為數(shù)據(jù)渲染手段之一顯示地圖之外，也能夠利用滾動(dòng)滑塊在不同版本之間顯示該地圖的直觀版本變更歷史。如果能夠?qū)⑦@種方式推廣到Word文檔、PDF文件以及電子表格當(dāng)中，那么GitHub類協(xié)作機(jī)制將幫助更多使用此類格式構(gòu)建產(chǎn)品的人們加入到這個(gè)大家庭當(dāng)中。
GitHub即平臺(tái)
對(duì)于由其托管的數(shù)百萬項(xiàng)目而言，GitHub并不能滿足全部需求，但它允許人們?cè)诖嘶A(chǔ)之上構(gòu)建成果并將成果融入當(dāng)中。使用GitHub API的工具承載著大量來自現(xiàn)有庫的項(xiàng)目管理功能，其中包括Waffleio、HuBoard以及ZenHub等等。
像Travis以及Jenkins這樣的持續(xù)集成系統(tǒng)能夠使用狀態(tài)API報(bào)告與提交內(nèi)容相關(guān)的測試結(jié)果。此外，CRUD API則讓編程型提交內(nèi)容得以在庫當(dāng)中實(shí)現(xiàn)文件的創(chuàng)建、更新或者刪除操作。舉例來說，Ben Balter就曾經(jīng)利用它構(gòu)建過一款應(yīng)用程序，旨在從HTML格式內(nèi)獲取輸入信息、并將其附加在GitHub庫中的CSV文件當(dāng)中。
當(dāng)然，GitHub并不是一套適用于每位用戶的平臺(tái)。O’Reilly媒體的Atlas——一套用于發(fā)布多種書籍格式的托管系統(tǒng)——就直接建立在Git基礎(chǔ)之上。不過對(duì)于多數(shù)非長久使用Git的用例而言，GitHub的界面——以及不斷進(jìn)化的擴(kuò)展成果——必將成為一套強(qiáng)有力的綜合體。
協(xié)作的文化
與Git類似，GitHub也成為多種協(xié)作方式的立足根基。GitHub鼓勵(lì)各類關(guān)鍵性最佳實(shí)踐，例如在不干涉其它來源的前提下通過一次性分支實(shí)現(xiàn)pull request提交。而標(biāo)簽則作為配發(fā)給提交內(nèi)容及pull request的關(guān)鍵詞。（其它社交系統(tǒng)可能會(huì)調(diào)用這些標(biāo)簽，但Git標(biāo)簽會(huì)識(shí)別庫歷史當(dāng)中的特定點(diǎn)。）大家用不著強(qiáng)行使用標(biāo)簽機(jī)制，但一旦接觸——如果大家的團(tuán)隊(duì)采用了詳盡且具備高度一致性的用詞——那么由此產(chǎn)生的過濾視圖將幫助每個(gè)人快速了解項(xiàng)目的概貌。
建立實(shí)用的提交信息則是另一種促進(jìn)協(xié)作活動(dòng)的有效途徑。程序員往往會(huì)在提交信息當(dāng)中發(fā)揮幽默感，例如“我修改了一部分內(nèi)容”，并通過多年的實(shí)踐經(jīng)驗(yàn)學(xué)會(huì)了如何及為什么要更為高效地對(duì)工作內(nèi)容進(jìn)行闡述。不過大部分知識(shí)型員工并不會(huì)用這種格式化的小型單位劃分自己的工作成果、將其廣泛共享至空間中并以有意義的方式提供他人可資借鑒的描述內(nèi)容。
這些實(shí)踐方式全部基于一項(xiàng)共識(shí)性結(jié)論，即所有共享成果都應(yīng)當(dāng)進(jìn)行版本區(qū)分，而全部變更也都需要經(jīng)過嚴(yán)格控制并配備文檔記錄——這種最佳實(shí)踐絕不應(yīng)被僅僅限制在軟件開發(fā)領(lǐng)域當(dāng)中。我們都在以分布式方式處理日常工作，因此需要審慎配合、關(guān)注細(xì)節(jié)并培養(yǎng)團(tuán)隊(duì)意識(shí)。Git為程序員們打開了通往無限希望的廈門，而GitHub的誕生則成為引導(dǎo)全民邁向協(xié)作時(shí)代的偉大道路。
英文：http://www.infoworld.com/article/2886828/collaboration-software/github-for-the-rest-of-us.html
當(dāng)前名稱：GitHub：超越開發(fā)者、走向全民的偉大道路
文章網(wǎng)址：http://fisionsoft.com.cn/article/cosdhjd.html
