以前作為一個編程小白盲链，只是聽到過GitHub, 只知道是一個有很多開源項目的地方则奥，但實際上也不太清楚到底可以干嘛。然而自從入坑了擼代碼拥坛，由于為了部署我的博客網(wǎng)站赔桌，更好地管理和操作代碼，第一次正式接觸到了Git以及GitHub. 作為一個曾經(jīng)Git和GitHub傻傻分不清的小白渴逻，為了更好地記錄學習過程疾党，特撰寫這一系列Git的入門教程筆記。
解決的痛點
Git的誕生是因為Linux之父為了開源托管Linux龐大的代碼庫而花“整整”兩周所寫的一個管理系統(tǒng)惨奕，詳情可以自行百度谷歌雪位。Git作為一個版本控制軟件，這類系統(tǒng)軟件解決了工程師們在開發(fā)過程中梨撞，防止因為過多的版本迭代和代碼修改雹洗，而造成的管理混亂。拿我們日常用word來創(chuàng)作的情景來舉個栗子卧波，我們在寫文稿的時候时肿，不可能一下筆就能一口氣從頭寫到尾，一字不差的完成內心的構想港粱，對吧螃成。(你要說你可以，我王境澤就從這跳下去......吃個飯)查坪。寫完后寸宏，一檢查，難免會出現(xiàn)差漏偿曙，這時你想刪掉某些內容或者某個段落氮凝，然后又怕刪錯了待會找不回來，就備份了一個原稿望忆，然后經(jīng)過一通亂改罩阵，就又存存存竿秆。。稿壁。這時候估計你的桌面就像如此：
這時候幽钢，如此多的修改和備份就造成了過于混亂的界面，到時候想找到某處的修改記錄常摧，估計你想想都小頭爸爸的兒子。而且如果需要多人協(xié)作威创，你還要把你的文稿逐一拷貝落午，甚是麻煩。而這其實都是程序猿在開發(fā)中會遇到的一個棘手問題肚豺。而類似于Git的這種版本控制系統(tǒng)的誕生溃斋，就很好的額解決了這一類難題。它可以系統(tǒng)的記錄每一次開發(fā)過程中的更改記錄和版本歷史以及都是誰做出的修改都能詳細記錄吸申。就像下圖一樣梗劫。這樣就能大大的提升開發(fā)的效率！
集中式vs分布式
按照維基百科的解釋:
Git是一個分布式版本控制軟件
英文叫Version Control System. 為了更好地理解分布式截碴，那就不得不提另外一種曾經(jīng)流行的管理模式：集中式梳侨。集中式的版本控制系統(tǒng)就是把代碼集中統(tǒng)一存放到一個中央服務器，不論是誰要做什么事日丹，都需要去這個中央服務器把最新的代碼版本扒拉下來干活走哺，干完活以后，便又要再一次推送給中央服務器哲虾，表面上看好像沒什么大不了丙躏。但實際上這中模式有一種通病，便是一定要聯(lián)網(wǎng)才能工作束凑，如果處于局域網(wǎng)也許會好些晒旅，但使用互聯(lián)網(wǎng)，難免避免不了網(wǎng)速的問題汪诉。其次废恋，一旦當中央服務器掛了，就意味著代碼庫掛了扒寄，那就代表之前的努力都付諸東流了拴签。
相對的，分布式就可以更好地解決這個問題旗们，分布式版本管理系統(tǒng)蚓哩，并不需要這個所謂的中央服務器，每個人各自的電腦里面都有一個完整的代碼庫上渴，而且及時未能聯(lián)網(wǎng)岸梨，你也依舊能愉快的工作喜颁，等完成了任務，待到有網(wǎng)之時曹阔，再同步到遠程服務器即可半开。雖然說分布式的版本控制系統(tǒng)，不需要要一個明確的中央服務器赃份，但一般在實際的開發(fā)過程中寂拆，都會有這么一個東西，但它也僅僅只是扮演同步代碼的角色抓韩，而GitHub就是扮演著這個角色纠永。因為很少會在兩人電腦間推送版本的修改。要注意的一點谒拴，與集中式不同的是尝江，哪怕沒有這個“中央服務器”，大家也還是可以一樣的干活英上，只不過彼此交換的各自的修改內容會不大方便炭序。
不過，Git作為分布式版本控制系統(tǒng)所帶來的的好處可遠遠不止聯(lián)不聯(lián)網(wǎng)這么簡單的問題苍日，它還有強大的分支管理系統(tǒng)惭聂，這會在后面的系列中提及。
簡單介紹了Git,相信大家都有了一些初步的認識相恃，那現(xiàn)在就再簡單介紹下何為GitHub彼妻。剛剛有提到一下，GitHub扮演著托管Git代碼的“中央服務器”角色豆茫。的確侨歉，這其實就已經(jīng)很好詮釋了它的身份。Git是一個軟件揩魂，一個系統(tǒng)幽邓，而GitHub就是一個網(wǎng)站，一個基于Git而誕生的文件托管網(wǎng)站(不一定就是放代碼的火脉，也有人備份個人文件資料)牵舵。所以也就解釋了開頭為什么GitHub上有這么多開源項目的原因了。
更多詳情歡迎光臨我的博客：禾斗的小博客
