Giới thiệu về Git và sử dụng Github!

Thảo luận trong 'Kiến Thức Chuyên Nghành' bắt đầu bởi nmkhoi, 

1. 

   nmkhoiRoot

   Tham gia ngày:

   25 Tháng tư 2015

   Bài viết:

   858

   Đã được thích:

   620

   Điểm thành tích:

   93

   Nơi ở:

   /System

   Web:

   http://osx.vn

   
   

    
   Phần 1: Giới Thiệu
   Please login or register to view links- Hệ thống quản lý source phân tán, có lẽ nhiêu đó đủ để nói lên "tinh thần" của hướng tiếp cận mới của Git so với các hệ thống source control khác như SVN hay CVS. (Thật ra xu hướng Git không phải là mới, vì nó đang phát triển trên cộng động lập trình thế giới, cả Facebook, Twitter, Yahoo cũng đang dùng github: Please login or register to view links để quản lý source code của họ) 1 - CENTRALIZED (Mô hình quản lý source tập trung):
   
   CVS (Concurrent Versions System) và SVN (SubVersioN) với mô hình quản lý source code tập trung, là hai phiên bản được sử dụng phổ biến hiện nay. Các hệ thống này cho phép các cộng tác viên theo dõi sự thay đổi đang thực hiện và biết ai đang phát triển nhánh nào của source code. CVS ra đời trước, sau đó đến sự bùn nổ của SVN. SVN bản chất vẫn là CVS được cải tiến, nhưng có nhiều công cụ hỗ trợ hơn. Cả CVS và SVN đều có tư tưởng chung về cách làm việc chung giữa các thành viên theo mô hình (quản lý source code tập trung) như sau:
   
   *Có lẽ sự cải thiện lớn nhất của SVN từ CVS là bổ sung việc commit của các thành viên được gọi là Atomic Commit. Atomic Commit cho phép mỗi commit từ thành viên được upate đầy đủ hoặc không có gì cả, điều này rất có ý nghĩa khi máy chủ bị treo trong lúc commit. Với CVS khi máy chủ bị treo hay kết nối bị trục trặc thì việc commit có thể bị dở dang, không đầy đủ.
   
   *Với SVN, các commit có thể được roll-back lại trạng thái trước đó, trong khi CVS thì không thể undo.
   
   *Ngoài ra SVN tiện lợi hơn CVS trong việc đổi tên và di chuyển các tập tin, thư mục. Với SVN các tập tin được đổi tên hoặc loại bỏ vẫn mang theo đầy đủ history và meta data của nó trước đó, trong khi đó với CVS thì tập tin bị đổi tên hoặc di chuyển sẽ bị mất history trước đó. CVS cũng không thể đẩy bất cứ những thay đổi mới đến repositories cha mà chỉ có thể đẩy lên repositories con của nó, trong khi một số công cụ SVN có khả năng này.
   
   *Cả hai sử dụng giao thức độc quyền qua một kết nối SSH để đảm bảo an toàn thông tin đang được truyền đi trên mạng. SVN bổ sung WebDAV DeltaV, giao thức này được dựa trên HTTP và HTTPS cung cấp cho người dùng một tùy chọn để kết nối với các SVN qua web.
   
   Dù đây là những tính năng đơn giản nhưng đến nay CVS vẫn không thể hổ trợ vì bản thân kiến trúc của nó có thể gây lỗi trên một số thành viên trong dự án. Đối với hầu hết mọi người khi bắt đầu với source control, SVN là lựa chọn tốt hơn và hợp lý hơn (nó cung cấp cho người dùng các tính năng cần thiết đủ để đáp ứng nhu cầu cơ bản hằng ngày của một developer như: checkout, update, commit ...) Lý do duy nhất để tiếp tục sử dụng CVS là nếu bạn đang bị mắc kẹt với một hệ thống source code cũ trên CVS mà không có cách nào để move nó qua SVN ... Chia bùn cùng bạn ...
   
   1 - Tóm tắt:
   1. SVN mới hơn và tiên tiến hơn so với CVS.
   2. SVN cho phép atomic commit, CVS thì không.
   3. SVN có thể roll-back việc commit, SVN cho phép đổi tên và di chuyển file hoặc folder mà vẫn giữ nguyên history của nó, trong khi CVS thì không.
   4. SVN cho phép đẩy thay đổi lên repositories cha, trong khi CVS không
   5. SVN hỗ trợ hai giao thức mạng (trong số đó có HTTP và HTTPS trên nền web) trong khi CVS không hỗ trợ HTTP và HTTPS
   
   Như vậy ta thấy SVN thật chất chỉ là phiên bản cải tiến so với CVS, về mặt cơ bản cả 2 đều hoạt động như nhau: tất cả source code sẽ được đặt trên 1 server trung tâm, mọi thành viên đều làm việc trên source code đó.
   
   2 - DISTRIBUTED (Mô hình quản lý source phân tán)
   Do đó Git có thể nói là một hướng tiếp cận hoàn toàn mới so với SVN (CVS và SVN theo hướng CENTRALIZED - quản lý source code tập trung, còn Git theo hướng DISTRIBUTED - quản lý source code phân tán).
   Chúng ta thường dùng SVN chắc đã hiểu khái niệm CENTRALIZED là gì rùi, vậy thì DISTRIBUTED sẽ như thế nào đây:
   
   Với một vài hệ thông như Please login or register to view linksvà ngay cả CVS và SVN, repository gốc sẽ được lưu trữ trên server và lập trình viên sẽ checkout về một bản copy mới nhất từ source code trên server đó để làm việc. Và khi ta muốn apply thay đổi của ta từ local ta sẽ send yêu cầu đó lên server. Đó chính là nguyên tắc chung của source control. Source control ra đời để phục vụ nhu cầu cho nhiều hơn một developer để họ có thể làm việc với nhau trên cùng một project. Mỗi một developer sẽ có một source code và làm việc với nó, và cập nhật thay đổi của mình cho những người khác trong team biết.
   
   Việc cập nhật thay đổi của bạn đến server là theo nguyên lý của SVN và CVS, tức là không phân tán vì tất cả thay đổi đều tập trung ở server. Việc quản lý tập trung yêu cầu quyền truy cập đến server khi ta commit hoặc update từ những thành viên khác, chính họ cũng đưa thay đổi của mình lên server (để tránh conflic hoặc out of update).
   
   Git hoàn toàn đối lập: Quản lý phân tán của Please login or register to view linkslà một repositories không cần có chung một nơi để lưu trữ, mà mỗi thành viên sẽ có một repository ở local của họ. Tất cả thao tác ta làm việc với Git đều ở trên máy của ta, local repository, khi quyết định đưa những thay đổi đó lên server ta chỉ cần một thao tác "push" nó lên server. Chúng ta vẫn có thể share thay đổi của chúng ta cho thành viên khác, bằng cách commit hoặc update trực tiếp từ máy của họ mà không phải thông qua repositories gốc trên server (thông qua share ssh cho nhau). Và dĩ nhiên là mọi thao tác đều mang theo thông tin history với Git.
   
   Tính phân tán thì an toàn hơn so với tập trung, vì mỗi bản copy của thành viên đều là full copy từ repository gốc, khi server bị down, các thành viên vẫn có thể làm việc offline, họ vẫn có thể commit và update trên local của họ hoặc thậm chí với nhau mà không cần thông qua server. Khi server hoạt động trở lại, họ có thể cập nhật tất cả lên lại server.
   
   Với mô hình Git, Mỗi thành viên tham gia git sẽ có một repository trên local của họ: máy John's Mac ở đây có thể trở thành một repository server, sau khi copy source code từ repository server, với 2 repository client khác là John's Linux và John's Solairs, 2 máy này sẽ làm việc hoàn toàn với máy John's Mac như một mô hình git con khác.
   
   Phần II: Sử dụng
   1. Github là gì:
   Github Please login or register to view links , còn được gọi là social network dành cho developer đi vào hoạt động tháng 2 năm 2008, là một dịch vụ sử dụng hệ thống quản lý phân tán GIT giúp người dùng lưu trữ source code cho các dự án. Tính năng của GIT như bài trước mình đã nói, nó có mọi tính năng của một source control như SVN và hơn thế nữa.
   
   Github được viết bằng Ruby on Rails. GitHub cung cấp dịch vụ thương mại và cả tài khoản miễn phí cho các dự án nguồn mở. Theo khảo sát của người sử dụng Git vào năm 2009, Github hiện đang là server Git lưu trữ source code phổ biến nhất hiện nay (Ngoài ra, Gitorious Please login or register to view links cũng là server Git hoạt động giống Github được chú ý đến).
   
   439000 developer tạo hơn 1 triệu 350 ngàn repositories là một con số khá ấn tượng, cùng với một số khách hàng lớn của github như Twitter, Facebook, Yahoo ... cho thấy tính phổ biến của Github, cũng như cộng đồng lập trình thế giới tính nhiệm nó như thế nào.
   
   2. Tính năng API của Github:
   Ngoài những tính năng tuyệt vời của hệ thống quản lý source phân tán GIT nói chung (Chúng ta sẽ nói ở một bài cụ thể khác), Github còn hỗ trợ người dùng những tính năng quan trọng thông qua API sau:
   
   1) API to Update The Repository via HTTP: GitHub hỗ trợ người dùng có thể edit file source code từ web browser thông qua HTTP - POST
   
   2) API to Access Compare Views (Giới thiệu chức năng Compare Views Please login or register to view links): Tính năng này hỗ trợ người dùng review và so sánh code của dự án thông qua việc xem các commit, comments, các dòng khác nhau giữa 2 version của file code ... Tính năng này cũng thông qua HTTP - POST, người dùng có thể thực hiên trên web browser.
   
   3) API to Manage Service Hooks: GitHub hỗ trợ tính năng mở rộng post-receive hooks Please login or register to view links. Tính năng này cho phép người dùng đăng ký 1 URL của mình (như là một web hook) cho các respository. Bất cứ khi nào có người push source code của họ lên repository, GitHub thông báo cho bạn biết bằng cách POST thông tin (dạng JSON) về lần push đó đến URL mà bạn đã đăng ký trước đó. Còn rất nhiều API hữu ích khác, các bạn có thể xem tất cả tại đâyhttp://develop.github.com
   
   3. Cách thức làm việc với GitHub:
   Làm việc với GitHub nói riêng hay hệ thống GIT nói chung có 2 workflow chính là local workflow và server workflow.
   
   Bạn có thể làm mọi chuyện thay đổi source code ở local, sau khi đã thay đổi xong, bạn sẽ commit nhưng thay đổi đó lên server và bản lên server phải là bản hoàn chỉnh một tính năng nào đó, hoặc fix bug xong, test xong hoặc ít nhất bản đó phải chạy được. Không được commit code dở dang, chưa qua test lên repository server sẽ làm ảnh hưởng đến các thành viên khác, ngược lại bạn có thể làm điều đó ở repository local (Bạn cũng có thể tạo một branch ở server cho việc commit code dở dang hay tính năng chưa hoàn thành như từng làm với SVN, nó sẽ chiếm space ở server cũng như làm mất thời gian của bạn vào việc tương tác kết nối với server, vậy tại sao không commit nó lên repository local nhỉ, vừa nhanh thao tác lại không mất space của server.)
   
   Mở rộng: từ repository của github ta có thể theo phương thức của Git tạo bản build cho production site (trên đây cũng là một repository server) bằng cách push thay đổi (đã qua test kỹ càng) lên nó.
   Khi tương tác với repository server (cập nhật hay thay đổi) GITHUB đòi hỏi mã chứng nhận "Bạn là ai" thông qua so sánh SSH key ở local của bạn và SSH key trên server tương ứng với account mà bạn đã đăng ký với GITHUB trước đó.
   
   1) Làm việc với repository ở local: với 2 command thường dùng là git add và git commit
   
   git add: add file đã thay đổi vào stage
   git commit: commit các file đã add vào stage lên repository ở local
   Ngoài ra bạn xem một số command khác
   
   2) Làm việc với repository ở server github:
   
   Sau khi đã quậy tè le ở local , cuối cùng khi có một bản ổn định và hoàn tất (có thông qua test) ta sẽ quyết định cập nhật nó lên repository server với:
   
   

   • push: push thay đổi từ repository local lên repository server
   • fetch: cập nhật thay đổi từ repository server về repository local
   • pull/rebase: sao chép source code từ server về local workspace (tương đương checkout của SVN)

   4. Hướng dẫn sử dụng:
   1) Đăng ký tài khoản GitHub tại Please login or register to view links
   
   2) Download và cài đặt công cụ Git:
   
   Download tại đây Please login or register to view links có 3 phiên bản cho cả 3 HDH, Khi Cài đặt Git: Bạn nên chọn "Run Git From the Windows Command Prompt"
   
   3) Tạo SSH Key:
   
   SSH Key là một mã chứng nhận để bạn có quyền thao tác trên repository của GitHub, SSH Key sẽ mang tất cả thông tin về account của bạn.
   
   SSH Key này được tạo ra trên local máy của bạn và được chính bạn add vào GitHub. Khi bạn push source code của mình lên repository server, GitHub sẽ kiểm tra SSH key ở local của bạn và SSH key trên server của nó (mà bạn đã add trước đó) có giống nhau không. Nếu giống nhau nó xác nhận bạn có quyền thao tác trên repository server. Một account GitHub có thể có nhiều SSH Key trên server.
   
   Cách tạo SSH Key chứng nhận như sau:
   Mở Git Bash đã được cài đặt ở trên:
   
   - Step1: $ ssh-keygen -t dsa : khởi tạo SSH key
   - Step 2: Chọn đường dẫn cho file SSH key: C:/Users/your_computer_name/.ssh/id_dsa
   - Step 3: Nhập một password của bạn (nhập 2 lần)
   - Step 4: Bạn đã tạo key thành công key sẽ nằm tại địa chỉ C:/Users/your_computer_name/.ssh/id_dsa
   
   - Step 5: Add SSH Key local vào server GitHub:
   Đến địa chỉ file SSH key mà bạn đã tạo, mở file id_dsa.pub và copy tất cả nội dung key trong đó
   
   Add key vừa copy đó vào account GitHub tại Please login or register to view links:
   
   Khi bạn tương tác với server của GitHub, nó sẽ kiểm trra SSH key mà bạn đã thêm vào tài khoản của mình (hình trên) vơis SSH key trong file local mà bạn đã tạo ban đầu C:/Users/your_computer_name/.ssh/id_dsa
   Paste nội dung file SSH key ở local vào text field Key. Như vậy ta đã xong phần đăng ký SSH key (dĩ nhiên là bạn phải giữ private SSH key này nhé)
   
   4) Tạo repository cho project mới trên GitHub tại Please login or register to view links (sau khi bạn đăng nhập)
   
   Nhập thông tin của repository project của bạn:
   
   Tạo thành công bạn sẽ có giao diện web quản lý repository của bạn trên GitHub như sau:
   
   Lưu ý link URL của Git trong trang này rất quan trọng, nó giống link SVN mà bạn hay dùng để có thể thực hiện các thao tác lên source code server như: checkout, update, commit ...
   
   5) Khởi động với Git command line trên local:
   
   Step 1: Cấu hình thông tin của bạn:
   git config --global user.name "Tran Nam"
   git config --global user.email nam.tran.flash@gmail.com
   
   Step 2: Thao tác trên local
   
   Ta làm một ví dụ nhỏ, tạo một thư mục cho project trên local và 1 file text readme, nhiệm vụ của chúng ta là đưa file này lên repository server mà ta đã tạo ở trên
   
   

   • Tạo thư mục cho project : mkdir YOUR_PATH
   • Di chuyển đến thư mục vừa tạo: cd YOUR_PATH
   • Khởi tạo GIT cho thư mục này: git nit
   • Thêm file readme.txt vào "working stage" (lưu ý readme.txt này bạn đã tạo trước đó trong thư mục YOUR_PATH): git add readme.txt
   • Commit nó lên repository local của bạn: git commit -m "YOUR_COMMENT"

   Step 3: Thao tác với GIT server (hình trên)
   
   - Remote vào server: git remote add origin git@github.com:namheo1985/Demo.git (link này được lấy từ project mà bạn đã tạo trước đó trên github)
   - push thay đổi của mình lên server github ở nhánh master: git push origin master (Lưu ý để tránh out of update hay conflict từ source code server so với local, ta nên git pull hoặc git fetch, cập nhật thay đổi từ server về local, trước khi git push)
   
   Phần 3: Lý Do Sử Dụng
   1 - Linh động, phong phú và đa dạng phiên bản:
   Với nhiều workflow làm việc khác nhau, tạo ra nhiều phiên bản phong phú, đa dạng, từ đó thúc đẩy những hướng đi mới từ 1 source code gốc trong cộng đồng mã nguồn mở
   
   Với việc có nhiều repo trong Git, các thành viên có thể kết hợp code của họ với nhau thông qua việc merge repo local của họ với nhau, từ đó tạo ra nhiều phiên bản, nhiều tính năng phong phú và. Ta có thể thấy qua ví dụ sau:
   
   Với SVN phiên bản cuối cùng của ta nằm ở server và là phiên bản duy nhất tích hợp tất cả các tính năng mà dev commit lên. Ta không thấy được tính phong phú và đa dạng của các phiên bản ở đây.
   
   Hãy xem GIT làm gì với mô hình của nó:
   Đây là mơ ước của cộng đồng mã nguồn mở bấy lâu. Các dev có thể tự do tích hợp những tính năng hoặc source code của mình với nhau, để tạo ra rất nhiều phiên bản đa dạng từ một phiên bản gốc. Mỗi phiên bản có thể có một hướng đi mới, độc lập nhau. Sau đây là một số workflow phổ biến:
   
   a) SVN Style: Với Git ta vẫn có thể dùng nó theo cách hoạt động của SVN: Các developer đều đồng bộ dữ liệu và commit thay đổi trên một repo duy nhất
   
   b) Integration Manager Workflow: Đây là mô hình khá phổ biến hiện nay, GitHub và nhiều open source cũng đang áp dụng nó:
   
   

   • Integration manager là bộ phận sẽ tập hợp các function được các dev commit lên để kiểm tra xem có nên cập nhật function đó vào bản gốc không ?
   • Blessed Repo: là source code ổn định sau những thay đổi được Integration manager quản lý và tích hợp các function mới từ dev vào.
   • Ví dụ một cộng đồng có nhiều dev cùng phát triển một open source:
   • Khi một dev private muốn thêm function mà mình nghĩ ra, họ sẽ download source code ổn định từ Blessed Repo về. Sau khi hoàn thành function mong muốn dựa trên source code down về họ đưa lên Developer public của mình.
   • Các function trên Developer public được tập họp ở Integrate Manager cho việc chọn lọc, testing và cuối cùng sẽ được tích hợp lên Blessed Repo thành bản ổn định.

   c) Dictator and Lieutenants Workflow:
   
   Mô hình này được mở rộng từ Integration Manager Workflow. Thay vì với "Integration Manager Workflow" thì mỗi dev làm việc độc lập với nhau, không hợp tác với các thành viên khác. Với "Dictator and Lieutenants Workflow" thì các dev có thể làm việc với nhau, họ có thể merge trực tiếp repo của họ (thông qua share SSH) với người khác thành một lieutenant.
   
   Một lieutenant là một phiên bản tích hợp nhiều tính năng của nhiều dev. Các lieutenant sẽ được tập hợp về dictator, dictator sẽ làm nhiệm vụ giống Integration manager: quản lý, testing, chọn lọc và tích hợp lieutenant vào blessed repo khi đạt yêu cầu.
   
   2) Local Branching:
   Phần này nói về việc tạo branch của Git tốt hơn các source control khác. Hầu hết các source control việc tạo branch đều clone một phiên bản mới nhất từ repository gốc thành một thư mục mới trên server. Git cho phép bạn tạo nhiều branch độc lập ở máy local, từ đó các thao tác create, merge, delete các dòng code trong source code diễn ra rất nhanh, trong vài giây.
   
   Điều này có nghĩa là bạn có thể làm như sau:
   
   

   • Tạo một branch mới trên local của bạn để thử nghiệm ý tưởng của , commit thử nghiệm một vài lần lên branch đó, bùn bùn trở lại trạng thái trước khi tạo branch, rồi sau đó có thể trở lại branch đó hoặc merge code thử nghiệm đó vào trunk chính.
   • Bạn có thể tạo một branch chỉ chứa những gì cần đưa lên production site, hoặc là nơi bạn merge code cho việc testing và commit hằng ngày trên brach đó, xem nó như là một phòng thí nghiệm local.
   • Bạn có thể tạo nhiều brach mới cho mỗi tính năng mới mà bạn đang làm, vì vậy bạn có thể chuyển đổi qua lại giữa chúng dễ dàng hoặc xóa branch đó đi khi nó được sát nhập vào branch chính hoặc không còn sử dụng nữa
   • Trong khi tạo một brach để thử nghiệm, bạn nhận ra nó không hữu dụng nữa và chỉ cần xóa nó đi, không ai khác ngoài bạn thấy nó (ngay cả khi bạn đã đẩy các branch khác trong khi chờ đợi)

   Bạn có thể làm tất cả các điều trên với Git nhưng cần lưu ý khi push lên server gốc, bạn không được push tất cả các brach mà bạn tạo ra để thử nghiệm. Việc này thúc đẩy developer thử nghiệm các nhánh mới mà họ không cần phải lo lắng về việc phải lên kế hoạch như thế nào hay khi nào để sát nhập nhánh của họ vào nhánh chính, trong quá trình thử nghiệm mọi history của họ đều được lưu trữ ở local. Nếu branch thử nghiệm thành công thì tốt, không được thì họ đơn giản chỉ delete đi là xong. Khi tham gia phát triển một dự án mã nguồn mỡ, nếu dùng svn một người đóng góp khi mới tham gia sẽ không có quyền tạo branch trên server của họ, với Git bạn có thể tạo branch local cho những thử nghiệm của mình và có thể sát nhập nó vào trunk chính trên server khi thử nghiệm thành công.
   
   Lưu ý: tất cả các điều trên không phải các source control khác không làm đươc, mà đều có cách để làm nhưng chi phí thực hiện cao, có khả năng gây lỗi trong quá trình thực hiện hoặc làm phìn kích thước source ở server. Git được sinh ra theo mô hình quản lý phân tán thì đây là ưu điểm mà nó thực hiện được dễ dàng.