Abstract image of a woman sitting on books and studying on a laptop

[Đồ án môn học] - Đề tài: Tìm hiểu Git và Github

Matt Colonel, profile picture
Matt Colonel

Tài liệu này nghiên cứu về git và github, cung cấp kiến thức cơ bản và nâng cao về quản lý mã nguồn. Nó bao gồm hướng dẫn cài đặt, cách sử dụng các lệnh git, và việc chuyển đổi kho từ svn sang git. Bài báo cáo cũng thể hiện sự cảm ơn đến giảng viên và các thầy cô đã hỗ trợ trong quá trình thực hiện đồ án.

Technology
Related topics:
Version Control Insights
1 of 96
Downloaded 11 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
Most read
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
Most read
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
Most read
96
BỘ CÔNG THƯƠNG TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP THỰC PHẨM TP. HCM KHOA CÔNG NGHỆ THÔNG TIN ĐỒ ÁN MÔN HỌC Đề tài: TÌM HIỂU GIT VÀ GITHUB Giảng viên hướng dẫn: ThS. Trần Thị Bích Vân Sinh viên thực hiện: Mai Thành Tâm 2033172075 Vũ Quang Huy 2033172018 TP. HCM, Tháng 7 Năm 2020
NHẬN XÉT CỦA GIẢNG VIÊN HƯỚNG DẪN ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... Nhóm em chân thành cảm ơn! TPHCM, ngày…tháng…năm 202.. GIẢNG VIÊN
NHẬN XÉT CỦA GIẢNG VIÊN PHẢN BIỆN ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... Nhóm em chân thành cảm ơn! TPHCM, ngày…tháng…năm 202.. GIẢNG VIÊN
LỜI CẢM ƠN Trong thời gian làm đồ án một chỉ, nhóm em đã nhận được nhiều sự giúp đỡ, đóng góp ý kiến và chỉ bảo nhiệt tình của Thầy/Cô. Đầu tiên, nhóm em xin trân trọng gửi lời cảm ơn chân thành đến Th.S Trần Thị Bích Vân, cô đang là giảng viên hiện đang công tác tại trường Đại Học Công Nghiệp Thực Phẩm TPHCM, người đã tận tình hướng dẫn, chỉ bảo nhóm em trong suốt quá trình làm đồ án. Cô đã dùng tất cả kinh nghiệm quý báu của mình trong suốt những năm giảng dạy để giúp nhóm em không chỉ hoàn thành tốt hơn đồ án của nhóm, bên cạnh đó còn chỉ dạy nhóm em cách xử lý những tình huống mà các anh chị khóa trước trong quá trình báo cáo đồ án, khóa luận đã gặp phải. Nhờ chỉ dạy và khuyên răn của cô đã giúp nhóm em tự tin hơn trước khi báo cáo đồ án của mình. Em cũng xin chân thành cảm ơn các Thầy/Cô trong trường Đại Học Công Nghiệp Thực Phẩm TP. HCM, cũng như các Thầy/Cô trong khoa Công Nghệ Thông Tin đã dạy dỗ cho em những kiến thức từ những môn đại cương đến các môn chuyên ngành, giúp nhóm em có được cơ sở lý thuyết vững vàng và tạo điều kiện giúp đỡ em trong suốt quá trình học tập. Nhờ những đóng góp chân thành, thẳng thắn của Thầy/Cô, bạn bè đã làm nguồn cảm hứng, động lực góp phần giúp nhóm em có những ý tưởng bổ sung kịp thời nhằm đạt được kết quả tốt nhất cho đề tài đồ án này. Một lần nữa, nhóm em xin dành lời chúc quý giá nhất tới những quý ân nhân. Kính chúc Khoa Công Nghệ Thông Tin cũng như các quý Thầy/Cô lời chúc sức khỏe và ngày càng thành công trong sự nghiệp “người lái đò”. Do đây là một bài báo cáo đầu tiên của nhóm em nên vẫn còn nhiều thiếu sót, tầm nhìn hạn hẹp, trình bày còn sơ sài nên mong nhận được sự thông cảm của thầy cô cùng những nhận xét khách quan cho nhóm em lấy điều đó làm kinh nghiệm triển khai trong các bài báo cáo sau này.
MỤC LỤC CHƯƠNG 1: GIỚI THIỆU......................................................................................1 1.1 Source Code ..............................................................................................1 1.1.1 Khái niệm cơ bản.................................................................................1 1.1.2 Quản lý Source Code...........................................................................1 1.2 Các mô hình quản lý ................................................................................2 1.2.1 Mô hình quản lý tập trung ...................................................................3 1.2.2 Mô hình quản lý phân tán....................................................................5 1.2.3 Sự phổ biến của hai mô hình...............................................................6 1.3 Github (https://github.com) ....................................................................6 1.3.1 Sơ lược về Github................................................................................6 1.3.2 Lịch sử và sự kiện của Github.............................................................7 1.3.2.1 Lịch sử ...........................................................................................7 1.3.2.2 Sự kiện ...........................................................................................8 1.3.3 Phân loại Github..................................................................................9 1.3.4 Tính năng API của Github.................................................................10 1.3.5 Nền tảng làm việc của Github ...........................................................11 1.3.5.1 Thao tác với Repo ở Local ..........................................................11 1.3.5.2 Thao tác với Repo ở Server .........................................................12 1.4 Git ............................................................................................................12 1.4.1 Sơ lược về Git....................................................................................12 1.4.2 Lịch sử Git.........................................................................................12 1.4.3 Đặc điểm của Git...............................................................................13 1.4.3.1 Tương tác dữ liệu với Git ............................................................13 1.4.3.2 Cơ chế Snapshot của Git .............................................................14 1.4.3.3 Thao tác Local của Git................................................................14 1.4.3.4 Định dạng đối tượng trong Git....................................................15 1.4.3.5 Tính toàn vẹn của Git ..................................................................17 1.4.3.6 Tính dễ dàng trong Git ................................................................18
1.4.4 Ưu và nhược điểm của Git ................................................................18 1.4.4.1 Ưu điểm .......................................................................................19 1.4.4.2 Nhược điểm..................................................................................19 1.5 Các khái niệm trong Git và Github......................................................20 1.6 Git Remote Server..................................................................................23 1.6.1 Giao thức Local .................................................................................24 1.6.2 Giao thức HTTP ................................................................................25 1.6.2.1 Smart HTTP.................................................................................25 1.6.2.2 Dump HTTP.................................................................................25 1.6.3 Giao thức SSH...................................................................................26 1.6.4 Git daemon ........................................................................................27 1.7 Bài toán dung lượng trong Git..............................................................27 1.7.1 Git đóng gói.......................................................................................28 1.7.2 Git LFS..............................................................................................30 CHƯƠNG 2: CÀI ĐẶT GIT..................................................................................32 2.1 Các môi trường Git hỗ trợ.....................................................................32 2.1.1 Trên Linux.........................................................................................32 2.1.2 Trên Windows ...................................................................................33 2.1.3 Phiên bản GUI...................................................................................37 CHƯƠNG 3: TRIỂN KHAI...................................................................................38 3.1 Cấu hình Github.....................................................................................38 3.1.1 Tạo Github Repository ......................................................................38 3.1.2 Tạo Github Branch ............................................................................41 3.1.3 Sử dụng Github..................................................................................42 3.1.3.1 Lệnh Commit trên Github............................................................42 3.1.3.2 Lệnh Pull trên Github..................................................................43 3.1.3.3 Lệnh Merge trên Github..............................................................44 3.1.4 Xóa Github Repository......................................................................45 3.2 Cấu hình Git cơ bản...............................................................................46
3.2.1 Thiết lập ban đầu ...............................................................................46 3.2.1.1 Định danh ....................................................................................47 3.2.1.2 Kiểm tra cài đặt...........................................................................47 3.2.1.3 Trợ giúp.......................................................................................48 3.2.2 Các lệnh cơ bản .................................................................................49 3.2.2.1 Khởi tạo Git Repository ban đầu.................................................49 3.2.2.2 Cách Clone dự án bằng Git.........................................................52 3.3 Kết nối Git đến Github qua SSH ..........................................................54 3.3.1 Khái niệm SSH..................................................................................54 3.3.2 Cơ chế làm việc SSH.........................................................................54 3.3.3 Các bước tạo khóa và kết nối Github................................................54 3.4 Cấu hình Git nâng cao ...........................................................................58 3.4.1 Nhánh là gì, tại sao phải phân nhánh ................................................58 3.4.2 Tạo nhánh..........................................................................................59 3.4.3 Phân nhánh ........................................................................................59 3.4.4 Gộp nhánh .........................................................................................60 3.4.5 Xóa nhánh..........................................................................................61 3.5 Giải quyết xung đột trên Git .................................................................62 3.5.1 Xung đột tập tin trong một nhánh .....................................................62 3.5.2 Xung đột tập tin trong nhiều nhánh...................................................65 3.6 Cài đặt, cấu hình Git LFS......................................................................70 3.6.1 Cài đặt Git LFS..................................................................................70 3.6.2 Cấu hình Git LFS ..............................................................................71 3.7 Tích hợp với hệ thống SVN ...................................................................76 3.7.1 Giới thiệu SVN2Git...........................................................................76 3.7.2 Cấu hình Git – SVN ..........................................................................77 CHƯƠNG 4: KẾT LUẬN ......................................................................................83 TÀI LIỆU THAM KHẢO ......................................................................................85
DANH MỤC KÝ HIỆU, CHỮ VIẾT TẮT Viết tắt Tiếng Anh Tiếng Việt GUI Graphical User Interface Giao diện đồ họa người dùng SSH Secure Shell Giao thức điều khiển từ xa bảo mật VCS Version Control System Phần mềm quản lý phiên bản dự án LFS Large File Storage Lưu trữ tập tin dung lượng lớn HTTP HyperText Transfer Protocol Giao thức truyền tải siêu văn bản HTTPS HyperText Transfer Protocol Secure Giao thức siêu văn bản bảo mật API Application Programming Interface Giao diện lập trình ứng dụng SVN Subversion Hệ thống quản lý tập trung QA Quality Assurance Đảm bảo chất lượng CVCS Centralized Version Control System Hệ thống kiếm soát tập trung DVCS Distributed Version Control System Hệ thống kiểm soát phân tán
MỤC LỤC HÌNH ẢNH Hình 1- Mô hình Local VCS------------------------------------------------------------------2 Hình 2- Hai mô hình Version Control ------------------------------------------------------3 Hình 3- Mô hình CVCS -----------------------------------------------------------------------4 Hình 4- Rủi ro tồn động tập trung một chỗ ------------------------------------------------4 Hình 5- Mô hình DVCS -----------------------------------------------------------------------5 Hình 6- Xu hướng phát triển hai mô hình quản lý phiên bản----------------------------6 Hình 7- Trang chủ Github--------------------------------------------------------------------7 Hình 8- Dự án Arctic Code Vault -----------------------------------------------------------8 Hình 9- Tương tác dữ liệu với các VCS -------------------------------------------------- 13 Hình 10- Tương tác dữ liệu với Git ------------------------------------------------------- 14 Hình 11- Mô tả cơ chế Snapshot ---------------------------------------------------------- 14 Hình 12- Hàm băm trong Git -------------------------------------------------------------- 17 Hình 13- Website Trustradius đánh giá Git---------------------------------------------- 18 Hình 14- Local Repo và Remote Repo---------------------------------------------------- 20 Hình 15- Minh họa hành động Merge ---------------------------------------------------- 21 Hình 16- Minh họa hành động Commit--------------------------------------------------- 22 Hình 17- Minh họa các hoạt động của Staging------------------------------------------ 22 Hình 18- Công dụng Git Remote Server-------------------------------------------------- 23 Hình 19- Đường dẫn URL của Local Repo ---------------------------------------------- 24 Hình 20- Nhiều Commit tăng dung lượng Repo----------------------------------------- 28 Hình 21- Mô tả lệnh git gc ----------------------------------------------------------------- 28 Hình 22- Công cụ Git LFS------------------------------------------------------------------ 30 Hình 23- Website tải Git chính thức của nhà phát hành ------------------------------- 32 Hình 24- Lựa chọn Sublime Text làm Git Editor---------------------------------------- 34 Hình 25- Hai chương trình khởi chạy ứng với hai môi trường------------------------ 37 Hình 26- Công cụ bên thứ 3 hỗ trợ GUI cho Git---------------------------------------- 37 Hình 27- Nơi đăng ký tài khoản Github -------------------------------------------------- 38 Hình 28- Khởi tạo Github Repositories--------------------------------------------------- 39
Hình 29- Đặt tên cho Repo ----------------------------------------------------------------- 39 Hình 30- Mô tả Repo dự án ---------------------------------------------------------------- 39 Hình 31- Hai chế độ phân quyền của Repo Github ------------------------------------- 39 Hình 32- Template tùy chọn Repo Github------------------------------------------------ 40 Hình 33- Đặt tên nhánh trên Github ------------------------------------------------------ 41 Hình 34- Repo hiện có 2 nhánh------------------------------------------------------------ 42 Hình 35- Tạo pull request trên Github---------------------------------------------------- 44 Hình 36- Repo trên Github đã xóa -------------------------------------------------------- 46 Hình 37- Xem thông số mặc định---------------------------------------------------------- 47 Hình 38- Xem xét tham số name thuộc User--------------------------------------------- 48 Hình 39- Website tập hợp các lệnh config ----------------------------------------------- 48 Hình 40- Các lệnh config Git -------------------------------------------------------------- 48 Hình 41- Xem trợ giúp lệnh commit------------------------------------------------------- 49 Hình 42- Tạo một thư mục chứa tập tin -------------------------------------------------- 49 Hình 43- Tạo file dự án --------------------------------------------------------------------- 50 Hình 44- Tải Github Repo bằng file zip -------------------------------------------------- 53 Hình 45- Lấy về toàn bộ dự án------------------------------------------------------------- 54 Hình 46- Thêm khóa bí mật vào SSH - agent -------------------------------------------- 55 Hình 47- Nội dung khóa công khai-------------------------------------------------------- 56 Hình 48- Quy trình chia nhánh ------------------------------------------------------------ 58 Hình 49- Rẽ nhánh tại Snapshot C2------------------------------------------------------- 66 Hình 50- Hai nội dung xung đột gộp nhánh --------------------------------------------- 68 Hình 51- Giữ lại nội dung của Master---------------------------------------------------- 68 Hình 52- Lịch sử Commit trên Alpha ----------------------------------------------------- 69 Hình 53- Lịch sử Commit trên Master ---------------------------------------------------- 69 Hình 54- Trang chủ tải Git LFS cho Windows ------------------------------------------ 70 Hình 55- Mô hình sử dụng Subversion clients------------------------------------------- 77 Hình 56- Giao diện VisualSVN Server---------------------------------------------------- 78 Hình 57- Giao diện TortoiseSVN---------------------------------------------------------- 78
LỜI NÓI ĐẦU Với tốc độ phát triển như vũ bão của ngành Công Nghệ Thông Tin, kéo theo sự đòi hỏi tỉ mỉ, chính xác và nhanh chóng trong việc tạo ra sản phẩm để đáp ứng nhu cầu xã hội. Một trong những vấn đề đang được quan tâm trong công nghệ là vấn đề về mã lệnh. Khi lập trình, có trường hợp lập trình viên sơ xuất xoá đi một đoạn mã lệnh quan trọng mà họ muốn lấy lại đoạn mã lệnh đó trong một chương trình dự án lớn có thể gây khó khăn cho họ. Ngoài ra việc nhớ lại chính xác những gì mình đã viết lại là một trở ngại khác. Việc sử dụng phần mềm quản lý phiên bản mã nguồn sẽ giúp mọi việc đơn giản hơn rất nhiều vì phần mềm cho phép người dùng quay lại phiên bản chỉnh sửa trước của tập tin dễ dàng. Việc lập trình giống như một ngành sản xuất, lập trình viên tạo ra sản phẩm phục vụ khách hàng, không ngừng cải tiến sản phẩm của mình sao cho phù hợp với nhu cầu thị trường, hỗ trợ tốt cho khách hàng. Để mọi việc dễ dàng hơn, bản thân lập trình viên thực sự cần đến một công cụ để quản lý sản phẩm của mình. Như các sản phẩm hàng hoá khác người dùng có thể dùng các phần mềm quản lý kho, quản lý dây chuyền sản phẩm, v.v. Đối với phần mềm, chúng ta có các công cụ quản lý phiên bản mã nguồn lệnh có thể kể đến như Git, SVN, Subversion, Mercurial, ... Mỗi công cụ có những đặc điểm và ưu thế riêng, trong số các công cụ này, Git cùng Github là bộ đôi công cụ quản lý mã nguồn lệnh phổ biến nhất và cũng là chủ đề chính của bài báo cáo này, nội dung được cô đọng trong những ý sau: - Giúp người dùng có cái nhìn tổng quát về công cụ quản lý mã nguồn lệnh nói chung và Git nói riêng. - Hiểu được cơ bản cách Git hoạt động và nên áp dụng như thế nào cho dự án của mình. - Tìm hiểu cách cài đặt Git và sử dụng Github trên nền Web - Làm quen với một số câu lệnh cơ bản của Git - Tìm hiểu một số lệnh nâng cao trong Git - Demo một số lệnh - Chuyển đổi kho SVN sang Git - Trộn kho code Từ các nội dung trên, những công dụng hữu ích cùng sự tiện lợi đến không ngờ của Git/Github sẽ được nhóm em đưa ra trong bài báo cáo.
1 CHƯƠNG 1: GIỚI THIỆU 1.1 Source Code 1.1.1 Khái niệm cơ bản Source Code (mã nguồn) theo định nghĩa trong tin học là một dãy các tập lệnh được viết bởi lập trình viên sử dụng các ngôn ngữ lập trình. Mã nguồn được xem là thành phần cơ bản của chương trình máy tính. Các lập trình viên có thể đọc và hiểu rõ mục đích của nó. Dựa vào trình biên dịch, mã nguồn của chương trình chuyển đổi thành ngôn ngữ mà máy tính có thể hiểu, có thể thực hiện gọi là ngôn ngữ máy. Mã nguồn có thể là “mở” hoặc “độc quyền” dựa theo các thỏa thuận cấp phép của chủ sở hữu. Một ví dụ điển hình là bộ phần mềm Microsoft Office có mã nguồn độc quyền thuộc Microsoft chỉ cấp cho khách hàng quyền truy cập vào các tệp thực thi và tệp thư viện liên quan hoặc một ví dụ khác là bộ phần mềm Apache OpenOffice có mã nguồn mở có thể được tải xuống và chỉnh sửa. Mục đích của mã nguồn cung cấp nền tảng cho việc tạo phần mềm, cho người dùng vào tùy chỉnh dễ dàng các thiết lập nếu cần. Các nhà phát triển sử dụng mã nguồn tạo các chương trình tương tự có tùy chỉnh sử dụng cho các nền tảng vận hành khác nhau, có thể xem Android của Google là một ví dụ khi từ nó, một phiên bản ROM gốc làm phần vùng lưu trữ hệ điều hành cho điện thoại thông minh, có đặc điểm “mở” cho phép các hãng sản xuất điện thoại tùy biến thành phiên bản ROM OS dành riêng cho sản phẩm điện thoại của riêng họ. Ngoài ra, việc giúp truy cập mã nguồn dễ dàng giúp các lập trình viên đóng góp cho cộng đồng công nghệ, chia sẻ mã nguồn cho mục đích học tập, tái chế các thành phần của nó cho các ứng dụng khác. Các lập trình viên sử dụng trình soạn thảo văn bản, công cụ lập trình trực quan hoặc môi trường phát triển tích hợp (IDE) như bộ công cụ phát triển phần mềm (SDK) để tạo mã nguồn. Trong môi trường phát triển chương trình lớn, các hệ thống quản lý phiên bản (Version Control System) có công dụng hỗ trợ lập trình viên phân nhánh, theo dõi, giám sát trạng thái và cấp độ khác nhau của các tệp mã nguồn. 1.1.2 Quản lý Source Code Version Control System là hệ thống quản lý phiên bản mã nguồn, một phần mềm giúp các lập trình viên, đặc biệt trong lĩnh vực phần mềm làm việc được với nhau và duy trì đầy đủ công việc vì tính năng không cho phép ghi đè lên các thay đổi của nhau. Hệ thống được cả doanh nghiệp lớn, nhỏ sử dụng do lợi ích thuận lợi, tiết kiệm một khoản chi phí. Hệ thống này là công cụ ghi lại các thay đổi của một file,
2 cấu trúc chương trình, từ các tệp mã lệnh cho đến các tệp hình ảnh, video. Cơ chế hoạt động và lợi ích có thể hiểu như sau: - Tạo ra các phiên bản khác nhau của dự án, dễ dàng cho việc giám sát. - Có ích cho các ngành nghề như lập trình viên, người làm đồ họa hay thiết kế web. - Sử dụng công cụ quản lý khôn ngoan có thể giúp người dùng chuyển qua lại các trạng thái hoặc toàn bộ cả dự án nếu muốn, so sánh với các thay đổi theo thời gian, xem người nào là người cuối cùng chỉnh sửa gì đó, ai là người phải chịu trách nhiệm. Từ những điều trên cho thấy công cụ Version Control mang lại lợi ích, trợ giúp nhiều cho một dự án – nhất là dự án liên quan đến code, một team có thể tự chia tạo ra một phiên bản riêng (Branch) cho mình, làm việc độc lập trên đó và sau đó sẽ gộp (Merge) mã lệnh lại. Mọi thứ còn lại đều được Version Control đánh dấu thời gian rõ ràng, theo dõi, phân tích tiến độ dự án, giúp công việc tiện lợi hơn rất nhiều. 1.2 Các mô hình quản lý Giải pháp đơn giản nhất sử dụng trước đây khi người dùng chuyển thư mục họ cần sang một thư mục khác. Được xem là một thao tác khá đơn giản. Tuy nhiên, điểm yếu của giải pháp này là người dùng có thể quên đường dẫn và vô tình ghi hoặc sao chép nhầm tập tin mà mình không mong muốn. Hình 1- Mô hình Local VCS
3 Từ đó, các lập trình viên đã phát triển ra Local VCS có một cơ sở dữ liệu đơn giản để giữ tất cả sự thay đổi của file dưới hệ thống kiểm soát sửa đổi. Công cụ đại diện cho giải pháp này là RCS, được phân phối sử dụng với nhiều máy tính hiện nay. Hai mô hình phổ biến nhất của VCS là mô hình quản lý phiên bản phân tán (CVCS) và mô hình quản lý phiên bản tập trung (DVCS) Hình 2- Hai mô hình Version Control 1.2.1 Mô hình quản lý tập trung Centralized Version Control System (CVCS): hệ thống quản lý phiên bản tập trung sử dụng một server để chứa tất cả lịch sử hay phiên bản mã nguồn và số lượng client kết nối vào để lấy file rất nhiều, tập trung tại một nơi. Để làm việc với dự án, trước hết, người dùng hoặc khách hàng cần lấy mã từ kho lưu trữ chính hoặc máy chủ. Máy khách cần liên lạc với máy chủ để kéo tất cả các mã nguồn hay phiên bản hiện tại từ máy chủ sang máy cục bộ của họ. Nói cách khác, người dùng cần lấy một bản cập nhật từ kho lưu trữ chính và sau đó nhận một bản sao mã nguồn cục bộ trong hệ thống của mình. Khi nhận được phiên bản mã nguồn mới nhất, máy khách thực hiện các thay đổi của riêng mình trong mã nguồn, sau đó hợp nhất mã nguồn của riêng họ vào kho lưu trữ chính hoặc tạo một phiên bản mới từ mã nguồn đó. Ưu điểm: - Giải quyết vấn đề các lập trình viên muốn làm việc với nhau trên các hệ thống khác nhau
4 - Có lợi ích với local VCSs, mọi người đều biết tiến độ công việc của thành viên khác trong dự án - Người quản trị có toàn quyền quyết định công việc của mỗi thành viên trong nhóm - Dễ dàng quản trị, kiểm soát, phân quyền dẫn tới cơ chế bảo mật Nhược điểm: - Nếu server bị sập trong một khoảng thời gian nào đó thì không một ai có thể làm việc hay lưu file trong khoảng thời gian đó - Nếu ổ đĩa cứng chứa cơ sở dữ liệu bị gián đoạn, hay là chưa có bản backup, toàn bộ lịch sử phiên bản của dự án sẽ bị mất hết Hình 3- Mô hình CVCS Sở hữu toàn bộ phiên bản dự án tập trung vào một nơi thì rủi ro xảy ra rất cao, đây là khi xuất hiện mô hình DVCS. Những công cụ tiêu biểu dành cho mô hình quản lý tập trung là SVN, CVS, Perforce … Hình 4- Rủi ro tồn động tập trung một chỗ
5 1.2.2 Mô hình quản lý phân tán Distributed Version Control System (DVCS): Hệ thống quản lý phiên bản phân tán ra đời để khắc phục nhược điểm của CVCS, được xem là một xu hướng hiện nay của hệ thống quản lý phiên bản. Hệ thống hoạt động theo mô hình ngang hàng, cơ sở mã nguồn được phân phối giữa các máy tính của máy khách, nhà phát triển riêng lẻ. Bản sao của cơ sở mã nguồn được lưu trên máy khách. Các nhà phát triển thực hiện chỉnh sửa trong bản sao cục bộ cùa họ. Khi họ muốn tích hợp vào bản sao chính, họ phải đưa yêu cầu cho chủ sở hữu bản sao chính đồng ý hợp nhất các thay đổi đó vào bản sao chính. Nhóm em xin trình bày những cơ chế cũng như ưu điểm của hệ thống quản lý phân tán qua các ý sau: - Giống với CVCS có một máy chủ chứa cơ sở dữ liệu lưu trữ các phiên bản của file - Các máy khách kết nối vào server không chỉ lấy file mà còn lấy luôn cả hệ thống cơ sở dữ liệu - Khi server bị sập, các máy khách vẫn làm việc được bình thường, thao tác trên cơ sở dữ liệu lưu ở máy trạm, sau đó có thể commit (chuyển) lên server nếu được phục hồi - Nếu cơ sở dữ liệu ở server, máy khách cũng có thể được xem là giải pháp Backup để phục hồi cho server Hình 5- Mô hình DVCS Ngoài ra, rất nhiều hệ thống phân tán còn hoạt động tốt với một vài hệ thống Remote Repositories, người dùng có thể tương tác với nhiều nhóm người dùng khác
6 nhau trong nhiều cách chỉ với trong một dự án. Điều này cho phép bạn thiết lập một số loại quy trình công việc mà trở nên bất khả thi trong CVCS – đó chính là một số loại mô hình phân tán. Các công cụ tiêu biểu của loại mô hình hệ thống này là Git, Mercurial, Bazaar…. 1.2.3 Sự phổ biến của hai mô hình Hình 6- Xu hướng phát triển hai mô hình quản lý phiên bản Google đã đưa ra một bảng xu hướng cho thấy mức độ phổ biến của hai mô hình hệ thống hiện đang được sử dụng trên toàn thế giới. Dựa vào kết quả, ta thấy được DVCS có nhiều ưu điểm hơn và phổ biến hơn CVCS. Về việc chọn lựa sử dụng hệ thống nào còn tùy thuộc vào đối tượng người dùng hoặc một người mới bắt đầu làm quen với hệ thống mang lại cho họ sự thuận tiện. Tuy nhiên, bản chất DVCS vẫn mang lại nhiều lợi ích hơn cùng những câu lệnh vận hành của nó. 1.3 Github (https://github.com) Ở nội dung này, nhóm em sẽ trình bày về hệ thống quản lý mã nguồn Github, đồng thời đóng vai trò là Server của Git. Github rất phổ biến, luôn là gợi ý đầu tiên cho người dùng có nhu cầu quản lý mã nguồn lệnh của mình trước khi họ biết đến Git. 1.3.1 Sơ lược về Github Github, một hệ thống quản lý dự án lớn nhất dành cho Git Repository, là nguồn lưu dữ liệu mở lớn nhất hiện nay. Nó được xem là một dịch vụ Server trung tâm công cộng giúp quản lý nhiều phiên bản Code, lưu trữ chúng và là một mạng xã hội giúp cho lập trình viên tương tác lẫn nhau. Với khả năng lưu trữ và độ bảo mật cao, một tỷ lệ lớn các kho Git đều được lưu trữ trên Github và nhiều dự án mã nguồn mở khác.
7 Hình 7- Trang chủ Github Github là sự kết hợp giữa 2 từ Git và Hub mang ý nghĩa như sau: - Git: hệ thống quản lý dự án và phiên bản code - Hub: nơi biến những dòng lệnh trong Git thành một mạng xã hội Github kế thừa toàn bộ tính năng của Git, nhiều người nói rằng Git chính là trái tim của Github. Github được sử dụng chủ yếu cho dự án có nhiều người hợp tác, lên kế hoạch, cần giám sát toàn bộ thay đổi của dự án từ mức độ nhỏ đến lớn. Bên cạnh đó, nó còn khả năng khôi phục code khi cần thiết. Github trở thành yếu tố có sức ảnh hưởng lớn trong cộng đồng mã nguồn mở. Kết hợp với Linkedin, Github có thể xem như một CV cho các ứng viên muốn tìm kiếm việc làm. Việc tham khảo hồ sơ Github của ứng viên là một điểm cộng cũng như sự thú vị đối với các nhà tuyển dụng. Từ đây, kỹ năng sử dụng Git và Github trở thành điều kiện bắt buộc trong câu chuyện tìm việc làm thuộc giới CNTT. 1.3.2 Lịch sử và sự kiện của Github 1.3.2.1 Lịch sử Github ra đời nhằm cung cấp dịch vụ kho lưu trữ mã nguồn từ xa cho Git dựa trên nền tảng Web. Nền tảng được phát triển vào ngày 19 tháng 10 năm 2007 bằng ngôn ngữ Ruby và trang web được đưa vào hoạt động chính thức tháng 4 năm 2008 bởi Preston-Werner, Chris Wanstrath và PJ Hyett. Đến tháng 4 năm 2016, github có hơn 14 triệu người sử dụng với hơn 35 triệu kho mã nguồn. Vào tháng 3 năm 2018,
8 github trở thành dịch vụ máy chủ phổ biến dành cho mã nguồn mở. Vào ngày 4 tháng 6 năm 2018, github đã được thỏa thuận mua lại bởi Microsoft với giá 7.5 tỷ Đô la Mỹ. Hiện nay, với hơn 25 triệu người dùng và hơn 80 triệu mã nguồn dự án, Github đã trở thành một phần không thể thiếu đối với cộng đồng phát triển mã nguồn mở và cộng đồng lập trình viên trên toàn thế giới. 1.3.2.2 Sự kiện Lo sợ về thời điểm tận thế có thể xảy ra đến nhân loại bất cứ lúc nào, tạo mối nguy cho lượng dữ liệu khổng lồ do con người tạo ra hàng chục năm, Github đã đưa ra một dự án đang được giới công nghệ quan tâm với tên gọi Archive Program. Dự án có mục đích nhằm bảo tồn toàn bộ kho dữ liệu khổng lồ bằng cách chôn chúng một cách an toàn tại nơi tận cùng của Trái Đất đó là Bắc cực. Sau gần một năm kể từ thời điểm công bố, Giám đốc chương trình chiến lược Github, Julia Metcalf, đã thông báo cho biết bộ sưu tập mã nguồn mở trong nhiều thập kỉ của Github đã được gửi thành công 21 TB dung lượng mã nguồn vào kho chứa an toàn ngày 8 tháng 7 năm 2020 dù chậm tiến độ tới 5 tháng do ảnh hưởng của đại dịch COVID – 19. Hình 8- Dự án Arctic Code Vault Những dữ liệu bảo tồn ban đầu tổng cộng hơn 6.000 ứng dụng mã nguồn mở quan trọng, bao gồm mã nguồn cho hệ điều hành Android và Linux, cũng như ngôn ngữ lập trình, nền tảng Web, tiền mã hóa và các công cụ AI. Khối dữ liệu nằm chung với các tài liệu bảo tồn dưới dạng kỹ thuật số của các quốc gia nằm khắp nơi trên thế giới,
9 bao gồm các tác phẩm nghệ thuật, âm nhạc, các đột phá khoa học… Khối dữ liệu bảo tồn rất có ích trong trường hợp tận thế diễn ra, nó đóng vai trò là chiếc kén thời gian, lưu lại các giá trị hỗ trợ con người xây dựng lại nền văn minh công nghệ cho thế giới sau hậu tận thế. 1.3.3 Phân loại Github Github được xem là dịch vụ máy chủ Repository công cộng, nơi mọi người dễ dàng truy cập, khi các máy tính có thể clone lại một mã nguồn trên Repository lưu trữ tại Github. Người dùng cần tạo một tài khoản để sở hữu cho mình một kho chứa riêng. Github cung cấp dịch vụ này dưới 2 hình thức: miễn phí và tính phí. Github phiên bản có phí sẽ nhắm vào đối tượng là doanh nghiệp sử dụng để quản lý nhóm cũng như phân quyền bảo mật dự án. Phần lớn người dùng còn lại sẽ tạo tài khoản miễn phí để lưu trữ Source Code và chính điều này đưa Github tiếp cận đến nhiều đối tượng rồi trở nên phổ biến như ngày nay. Đến tháng 9 năm 2019, giá dịch vụ phiên bản trả phí của Github cụ thể như sau: - Github Individuals: bản cá nhân có giá từ 0 – 7$. Với gói Pro 7$, người dùng sẽ có nhiều tính năng hơn như: Draft pull requests, Code owners, Pages and wikis, Repository insights… cùng nhiều tính năng khác - Github Team: giá từ 9$ trở lên. Mức giá sẽ tăng tùy vào mô hình doanh nghiệp cần triển khai thông qua việc báo giá. Sử dụng gói dịch vụ với giá càng cao thì Github càng mang lại sự toàn diện Github cung cấp thêm tính năng mạng xã hội như Feeds, Follower và Network Graph tạo sự kết nối giữa các lập trình viên, cung cấp cho họ một cộng đồng để học hỏi kinh nghiệm lẫn nhau thông qua các các lịch sử Commit.
10 1.3.4 Tính năng API của Github API là từ viết tắt của Application Programming Interface – phương thức trung gian kết nối các ứng dụng và thư viện khác nhau. Việc sử dụng API tạo sự thuận tiện cho lập trình viên đẩy nhanh quá trình phát triển phần mềm, tạo ra sự nhanh chóng, nâng cao hiệu suất công việc. Ngoài Git thì API còn được xem là một tính năng quản lý khá toàn diện cho Github. Tính năng hỗ trợ lập trình viên và người dùng quản lý nguồn dữ liệu của mình hiệu quả và khoa học. Sau đây, nhóm em sẽ đưa một vài tính năng quan trọng của API trong Github: - API to Update The Repository via HTTP: Đây là tính năng khá đắt, cập nhật kho lưu trữ thông Web Browser, cho phép chỉnh sửa các tập tin mã nguồn thông qua giao thức HTTP – POST - API to Access Compare Views: Hỗ trợ người dùng so sánh Code với dự án qua việc xem Commit, Comments, đồng thời đưa ra nhận xét thông qua Web Browser - API to Manage Service Hooks: Cho phép người dùng đăng ký một đường dẫn URL cho các kho lưu trữ, khi có người đẩy lên Repo, Github sẽ thông báo thông qua URL này Ngoài ra, Github còn sở hữu nhiều tính năng API khác rất hay. Việc sơ lược về các tính năng này nhằm cho thấy sự tiện lợi của API trong Github.
11 1.3.5 Nền tảng làm việc của Github Quy tắc làm việc trên Github diễn ra trên hai nền tảng đó là Local Workflow và Server Workflow. Người dùng thay đổi Source Code ở Local rồi xác nhận sự thay đổi đó ở Server. Bản xác nhận phía Server phải là một phiên bản có chứa tính năng hoàn chỉnh hoặc có thể chạy được. Việc xác nhận các đoạn Code chưa hoàn chỉnh sẽ làm ảnh hưởng thành viên khác khi họ sử dụng chung kho lưu trữ. Từ kho lưu trữ này, người dùng có thể tạo các bản Build cho dự án gốc bằng cách gửi các Source Code có sự thay đổi lên đó. Với vấn đề bảo mật và kiểm soát quyền truy cập, mỗi người dùng khi sử dụng kho lưu trữ của Github phải cung cấp mã chứng nhận, có thể sử dụng một cặp khóa trong giao thức SSH, hệ thống sẽ so sánh SSH Key ở Local và trên Server tương ứng với Account nào đã được chính người dùng đó đăng kí. Các thao tác đối với hai nền tảng này của Github diễn ra thông qua các câu lệnh, thuật ngữ sẽ được nhóm em trình bày cụ thể ở tiêu đề 1.5 của bài báo cáo. 1.3.5.1 Thao tác với Repo ở Local Các thao tác dòng lệnh diễn ra ở Local hầu như đều là các dòng lệnh cơ bản của Git, trong đó, hai dòng lệnh nổi trội thường được nhiều đối tượng người dùng sử dụng là git add và git commit: - git add: thêm tập tin đã được thay đổi vào Stage - git commit: các tập tin trong Stage sẽ được đưa qua Repo của Local
12 1.3.5.2 Thao tác với Repo ở Server Khi người dùng hoàn tất tất cả quy trình, tạo ra một phiên bản ổn định của dự án ở Local, họ có thể quyết định cập nhật tập tin dự án đó lên Repo tại Server với ba câu lệnh sau là chủ yếu: - push: push các thay đổi từ Repo Local đến Repo Server - fetch: cập nhật thay đổi từ Repo Server về Repo Local - pull/rebase: sao chép Source Code từ Server về Local Workspace 1.4 Git 1.4.1 Sơ lược về Git Git là một đại diện tiêu biểu của hệ thống quản lý phiên bản phân tán DVCS mã nguồn mở, một trong những dạng hệ thống quản lý phiên bản phân tán phổ biến nhất hiện nay. Git có những đặc điểm sau: - Có hướng tiếp cận mới so với các hệ thống Source Control khác như SVN hay CVS truyền thống. - Có nhiệm vụ theo dõi những thay đổi, chỉnh sửa trong Source Code của người dùng vào mọi thời điểm và đồng bộ những Source Code do họ chỉnh sửa lên Server cùng đồng nghiệp. Ngoài ra, Git chạy được trên nhiều hệ điều hành khác nhau như Linux, Windows, MacOS… 1.4.2 Lịch sử Git Được xem là một sáng kiến hay và ra đời trong thời điểm xảy ra tranh chấp, git ra đời để thay thế BitKeeper vốn được dùng để chứa hàng ngàn dòng Code, bản vá và các tập tin của nhân Linux. Do mối quan hệ giữa nhóm lập trình viên phát triển nhân linux và công ty thương mại phát triển BitKeeper bị đổ bể dẫn tới bản thân BitKeeper bị thu hồi. Điều này dẫn tới cộng đồng phát triển nhân linux, bao gồm cả người tạo ra nó là Linus Torvards, tự phát triển một công cụ dựa trên những kiến thức được tiếp thu từ việc sử dụng BitKeeper. Git ra đời cùng với những yêu cầu được đề ra như sau: - Tốc độ - Thiết kế đơn giản
13 - Phân tán toàn diện - Phù hợp cho cả dự án lớn và nhỏ - Hỗ trợ mạnh mẽ cho hướng phát triển không tuyến tính Git sau đó phát triển mạnh mẽ, ảnh hưởng đến nhiều dự án lớn, và có cả một nhánh dành cho phát triển phi tuyến tính. Nhóm em xin tóm tắt quá trình hình thành Git qua các ý sau: - Git ra đời vào năm 2005 - Tác giả là Linus Torvald, đồng viết ra Linux kernel - Git vốn được phát triển để quản lý Source Code của Linux - Git trở thành phần mềm quản lý mã nguồn mở phổ biến và được phân phối theo giấy phép công cộng GPL2 1.4.3 Đặc điểm của Git 1.4.3.1 Tương tác dữ liệu với Git Đối với các VCS còn lại, git có hướng suy nghĩ khác biệt về dữ liệu. Hầu hết các hệ thống sẽ chứa thông tin như một danh sách các file được thay đổi, chỉ khi nào có một thao tác lưu lại “commit” thì chỉ duy nhất file thực thi lệnh đó mới được lưu trên server. Người dùng sẽ không thể thực hiện commit toàn bộ phiên bản trạng thái hiện tại, hệ thống sẽ ánh xạ đến lần lưu trữ file trước. Hình 9- Tương tác dữ liệu với các VCS Git xem dữ liệu như là một chuỗi “snapshot” của một hệ thống tập tin thu nhỏ. Mỗi lần người dùng “commit” hay lưu trạng thái của dự án, git sẽ chụp ảnh hết tất cả trạng thái phiên bản tập tin hiện tại và chứa nó như một tham chiếu đến snapshot đó. Khi file không thay đổi, Git sẽ tham chiếu đến lần lưu thông tin trước đó.
14 Hình 10- Tương tác dữ liệu với Git 1.4.3.2 Cơ chế Snapshot của Git Git lưu dữ liệu dưới dạng một ảnh chụp “Snapshot”, mỗi khi người dùng tiến hành lưu lại “commit” thì Git chụp lại hệ thống các file đó và lưu giữ một tham chiếu đến nó chỉ khi file có thay đổi, nếu không Git sẽ tham chiếu đến lần lưu trước đó. Hình 11- Mô tả cơ chế Snapshot 1.4.3.3 Thao tác Local của Git Mọi thao tác như thêm mới, xem lại lịch sử… với Git đều diễn ra tại cục bộ do mỗi máy trạm đều có một cơ sở dữ liệu Git. Ngoài ra, người dùng muốn đưa file dữ liệu lên một điểm lưu trữ khác hoặc muốn lấy file cập nhật của người khác thì lúc đó mới cần đến vai trò của server. Điều này giúp Git cải thiện tốc độ với việc sử dụng tài nguyên không đáng kể, bởi vì người dùng đã có toàn bộ dự án tại repo cục bộ của họ. Nó có ích cho người dùng khi họ Offline hay Off VPN, họ vẫn làm việc thoải mái và chỉ cần đợi trong điều kiện có mạng có thể up file lên. So với các hệ thống tập trung, họ sẽ không thể commit, push hay làm gì khi không kết nối tới cơ sở dữ liệu của server.
15 1.4.3.4 Định dạng đối tượng trong Git Git có một mục object được lưu trữ dùng để chứa file gốc và tất cả những tin nhắn log, chủ nhân file, ngày tạo và thông tin khác cần để tạo nên một sửa đổi hay nhánh cho dự án. Có 3 thành phần quan trọng của object cần chú ý: type, size, content. - Size: đơn giản là kích cỡ của nội dung - Content: dựa vào type (loại) của đối tượng - Type: loại đối tượng được chứa trong đường dẫn .git/objects, gồm 4 loại khác nhau, bao gồm: • blob: dùng để lưu file dữ liệu – là tập tin nhị phân của mỗi phiên bản file, đây còn là nguyên nhân dẫn đến sự gia tăng dung lượng kho chứa • tree: đơn giản là một đường dẫn • commit: giữ metadata cho mỗi lần file thay đổi trong kho lưu trữ, bao gồm chủ sở hữu, người gửi, dữ liệu commit, thông điệp nhật ký • tag: gán một tên có ý nghĩa mà người dùng đọc được cho một đối tượng cụ thể khi sử dụng commit Có một khái niệm liên quan đến cơ chế Snapshot của Git là loose object format (định dạng đối tượng trong suốt của git). Để thấy được thư mục đối tượng, người quản trị tạo 3 file lần lượt là 0.txt, 1.txt, 2.txt và sử dụng các lệnh commit, trong folder sẽ xuất hiện file .git. Git tạo 3 thư mục trong đường dẫn .git/objects lần lượt là 53, ab, e6
16 Trong mỗi thư mục sẽ có chứa một file mã băm gồm 40 kí tự với 2 kí tự là tên gọi của thự mục đường dẫn, 38 kí tự còn lại được dùng như tên file, người dùng gõ lệnh “git cat-file [-option] [ten_file]”, option được chọn ở đây là [-t] *Lưu ý: ten_file phải bao gồm đủ 40 kí tự, tức là bao gồm cả 2 kí tự tên thư mục đường dẫn Chỉnh sửa nội dung tập tin, Git sẽ tạo thêm 5 tập tin trên những tập tin cũ Thông qua câu lệnh git cat-file [-t], các thư mục băm với hai ký tự đầu sẽ được hiển thi rõ ràng nội dung cũng như tính năng tương tự
17 Bất cứ khi nào người dùng commit, git đều chụp lại vào ổ đĩa giữa phiên bản cũ và phiên bản mới trong cùng một file, kể cả ta chỉ thay đổi một kí tự nội dung file. 1.4.3.5 Tính toàn vẹn của Git Mọi thứ trong Git đều được kiểm tra “checksummed” trước khi được lưu trữ và được tham chiếu bởi Checksum này. Chức năng này cho Git biết mọi sự thay đổi trong một file hay một đường dẫn, nó bảo đảm tính toàn vẹn giúp người dùng không thể mất thông tin trong trường hợp trao đổi dữ liệu hay file lỗi không thể nhận ra. Một sự thật là Git đã lưu cơ sở dữ liệu không phải bởi tên file mà là giá trị hàm băm của chính nội dung file đó. Hàm băm Git sử dụng là SHA - 1, gồm 40 kí tự được tạo ra theo nội dung của file có độ dài 40 ký tự, được tích hợp ở tầng thấp nhất của Git và là một triết lý không thể thiếu của nó. Nó còn được xem là một “commit id”. Một ví dụ điển hình của hàm băm SHA - 1, ta sẽ thực hiện các lệnh sau: - “git show -s --format=%h” với kí tự ‘H’ là xem phiên bản đầy đủ - “git show -s --format=%h” với kí tự ‘h’ là xem phiên bản rút gọn của hàm băm Hình 12- Hàm băm trong Git
18 1.4.3.6 Tính dễ dàng trong Git Git đơn giản chỉ thêm dữ liệu vào cơ sở dữ liệu Git, khó làm cho hệ thống làm một việc gì đó mà không phục hồi lại được cũng như không thể xóa hoàn toàn dữ liệu khỏi hệ thống. Điều này khiến Git trở nên thú vị đối với những người dùng thích trải nghiệm mà không sợ những mối nguy làm hại hệ thống, vì Git chứa dữ liệu đó và giúp người dùng phục hồi nó. 1.4.4 Ưu và nhược điểm của Git Dựa vào những đặc tính và sự phổ biến của Git đối với người dùng, nhất là lập trình viên, ta sẽ đưa ra những lợi ích khi sử dụng Git. Tuy nhiên, một công cụ hay phần mềm nào cũng đều có lợi và hại. Vậy Git có nhược điểm gì và nó có độ ảnh hưởng như thế nào tới công việc mà người dùng vẫn bỏ qua và sử dụng Git? Hình 13- Website Trustradius đánh giá Git Để biết được hai điểm này, ta sẽ phải tham khảo thông qua những đánh giá của người dùng Git trên các diễn đàn, trang báo mạng do họ đã trải nghiệm sản phẩm, có thể là ít hoặc lâu dài, họ dành thời gian cho Git, nắm rõ được những tiện lợi của Git, đồng thời biết đến một vài bất tiện của nó. Tổng hợp, nhóm em sẽ tổng hợp những đánh giá trên website: https://www.trustradius.com/ để thấy được những ưu/nhược điểm của Git.
19 1.4.4.1 Ưu điểm Đa phần người dùng đều đánh giá, trong vô số công cụ thì Git lại là một “ông vua” thuộc mô hình DVCS. Họ đã khẳng định việc đó dựa vào những ưu điểm của Git, điều đã giúp nó trở thành công cụ phổ biến nhất hiện nay: - Mô hình phân tán – làm việc tại Local, không công khai, tốc độ phản hồi nhanh chóng, làm việc offline, truy cập mọi nơi, backup - Chia nhánh và gộp dễ dàng – có thể làm việc trên một nhánh riêng, tiết kiệm, nhanh và không chiếm nhiều dung lượng, khi xong ý tưởng riêng có thể gộp lại với nhánh chính - Quy trình làm việc linh hoạt – cho phép người dùng tạo một một quy trình làm việc riêng “Workflow” phù hợp, từ một quy trình chính phân ra các quy trình phụ - Đảm bảo toàn vẹn dữ liệu – quản lý dự án tuyệt vời bằng việc sử dụng cây hàm băm SHA-1, dữ liệu bị gián đoạn có thể bị phát hiện - Tích hợp trong nhiều công cụ khác - Mã nguồn mở, giúp tiết kiệm chi phí cho chủ doanh nghiệp - Cho phép một dự án có nhiều thành viên, tổ chức cùng code, testing kể cả ở cách xa nhau - Nhiều tài liệu và quy trình, cộng đồng hỗ trợ - Có giao diện dòng lệnh trực quan, dễ học và mở rộng khả năng, có thể triển khai dự án chỉ với một vài câu lệnh cơ bản, có nhiều tool dòng lệnh rất mạnh hỗ trợ người dùng cuối 1.4.4.2 Nhược điểm Bên cạnh những ưu điểm vượt trội trên, Git cũng tồn tại những vấn đề bất cập gây khó chịu cho người dùng. Đó chính là những nhược điểm sau đây: - Không có cách nào để tránh tải toàn bộ lịch sử commit của một dự án, nếu dự án có nhiều Module và Package thì đây là một vấn đề lớn - Hàm băm SHA – 1 trong kho Git xuất hiện nhiều điểm yếu do sự va chạm giá trị băm, một máy tính thông thường có thể âm thầm phá hủy giá trị băm này - Quá trình học sử dụng Git khá phức tạp, vài câu lệnh có Option không trực quan đòi hỏi người sử dụng phải có hiểu biết về quá trình hoạt động bên trong của Git, nhiều câu lệnh và cú pháp không đồng nhất ở vài cấp bậc
20 - Nếu dự án không có file dạng văn bản thì cập nhật thường xuyên sẽ làm Git giải quyết cồng kềnh và chậm chạp - Thiếu nhiều công cụ hỗ trợ giao diện cho Git Client 1.5 Các khái niệm trong Git và Github Trong Git và Github tồn tại nhiều thuật ngữ đòi hỏi người sử dụng, đặc biệt là những người dùng mới, phải làm quen, đọc nhiều tài liệu, tham khảo các trang mạng mới biết được ý nghĩa và công dụng của nó. Nhóm em sẽ trình bày những thuật ngữ cần quan tâm trong bài như sau: Repository: viết tắt là Repo, thường được xem là một dự án, một kho chứa chính cho toàn bộ mã nguồn lệnh, tập tin, thư mục có nội dung cần cho dự án trong hệ thống quản lý Version. Có thể xem nó là một đối tượng cơ sở dữ liệu chứa tất cả mọi thứ từ phiên bản, các phiên ủy thác, lịch sử thay đổi của nội dung và không giới hạn cho người chia sẻ và sao chép. Git chia Repo thành 2 loại mô tả thông qua hình sau: Hình 14- Local Repo và Remote Repo - Local Repository: thao tác trên máy tính cá nhân người dùng hoặc server phát triển ở vùng Local, dành cho người dùng sử dụng không cần Internet - Remote Repository: (tên gọi mặc định là Origin) nằm ngoài, thao tác thông qua Local, thao tác nhiều người dùng. Khi muốn chia sẻ nội dung công việc đã
21 làm ở Local thì ta sẽ tải lên Remote Repo để công khai nội dung công việc đó. Có 2 hệ thống Remote được sử dụng nhiều là Github và Bitbucket Working tree: (viết tắt là Tree) được xem là nhánh, chỉ mục làm việc hiện tại, nơi người dùng chỉnh sửa, tạo file mới. Index: nơi bảo trì trạng thái sau khi chỉnh sửa trên Working Tree, là đối tượng nằm giữa Repo và Tree, đưa tập tin thay đổi commit lên Repo. Branch: phân nhánh và ghi chép lịch sử, có 3 loại nhánh: - Local Branch: Branch quản lý trong Local Repository - Remote Branch: Branch trong Remote Repository - Remote Tracking Branch: Branch để Local Repository theo dõi Remote Branch Checkout: triển khai Branch ở Repo lên Tree, chuyển từ một nhánh sang một nhánh khác. Merge: trộn 2 hay nhiều Commit từ một nhánh khác vào nhánh hiện tại. Hình 15- Minh họa hành động Merge Conflict: đây là trường hợp có 2 sự thây đổi Code cùng lúc làm máy tính không xác nhận được Code “cần”. Lúc này, lập trình viên phải chỉnh tay thủ công, xóa bỏ dòng Code không cần thiết, một số IDE có hỗ trợ Extension cho phép ta chọn dòng Code ta cần xóa bỏ. Tag: tên được gắn thêm vào file để dễ dàng tham chiếu Commit. Commit: đây là những hành động thêm/thay đổi file hay thư mục vào Repo. Repository lúc này sẽ tạo ra commit (hoặc revision) để ghi lại sự khác biệt từ trạng
22 thái commit lần trước với trạng thái hiện tại. Các commit được chứa tại repo nối tiếp nhau theo thứ tự thời gian. Hình 16- Minh họa hành động Commit *Trong Commit sẽ có 2 trạng thái cần lưu ý: - Tracked: tập tin được đánh dấu theo dõi trong Git để người dùng làm việc, gồm thêm các trạng thái phụ khác là Unmodified (chưa chỉnh sửa), Modified (đã chỉnh sửa) và Staged (đã sẵn sàng để commit) - Untracked: tập tin còn lại mà người dùng không muốn làm việc với nó trong Git Staging: bất cứ khi nào người dùng thực hiện commit thì Git sẽ tìm kiếm file trong khu vực tổ chức (Staging Area) và chỉ những file trong khu vực này mới được xem xét để commit. Hình 17- Minh họa các hoạt động của Staging Revision: giá trị hash được tạo mỗi lần commit, do Git quản lý theo thế hệ. HEAD: là một điểm con trỏ, trỏ vào Commit mới nhất trong nhánh.
23 *Ngoài ra, Git còn hỗ trợ thêm các câu lệnh sau cho người dùng tương tác với hệ thống Git. Clone: đây là hành động tải xuống bản sao của một Repository Local, quá trình này cần kết nối Internet khi các Repository Instance đang được đồng bộ từ các Remote Repository. Fetch: tải về (fetch) dữ liệu của toàn bộ các Branch trên URL nhưng không thực hiện merge các thay đổi vào Local. Pull/Pull request: tải về (fetch) dữ liệu từ một Branch duy nhất từ Remote server và sau đó merge các thay đổi từ Remote này về Local Repository (đồng bộ từ Git server tới máy khách). Push: thao tác đẩy các thay đổi bản sao chép từ Repository Local lên Remote Repository, sử dụng để lưu thay đổi vĩnh viễn trong Repo Git, tương tự như commit. 1.6 Git Remote Server Hình 18- Công dụng Git Remote Server Ở mục tiêu đề này nhóm em muốn giới thiệu tổng quát về các giao thức được sử dụng đối với Git trên server cũng như công dụng của server đối với Git. Git server đơn giản đóng vai trò làm một máy chủ cài đặt Git, cho phép tạo Repository. Đơn cử là Github, Gitlab… sau đó cho phép người dùng “clone” nội dung về Local và có thể cập nhật lên lại Remote. Nó được xem như một Repo đứng giữa để nhiều người dùng,
24 thành viên dự án cùng đăng nhập vào, kể cả đang offline hay online, thực hiện push và pull dữ liệu qua nó. Hầu hết các thao tác làm việc của git đều xuất hiện ở local (máy client) với local repository, chỉ khi nào người dùng có nhu cầu làm việc nhóm hay đơn giản muốn làm ở nhiều máy khác nhau thì họ sẽ sử dụng đến remote repository hay còn gọi là repository ở phía server. Sử dụng Git như một server sẽ dễ kiểm soát cũng như phân quyền dễ dàng để quản lý các thành viên, khách hàng trong một dự án, luôn đảm bảo mức bảo mật cho dự án. Về phía các giao thức sử dụng hỗ trợ phía server, người dùng có thể dùng nhiều giao thức khác biệt để truyền dữ liệu: Local, HTTP, SSH và Git. 1.6.1 Giao thức Local Là giao thức cơ bản nhất trong số các giao thức Git trên server. Nó tạo một remote repository ở một đường dẫn khác trong cùng một host và dành cho nhóm người dùng muốn đăng nhập vào một hệ thống chia sẻ tập tin như NFS mount, hay như trường hợp mọi người cùng đăng nhập vào một máy tính. Người dùng có thể thực hiện các lệnh clone, push, pull từ local repository, một trường hợp clone từ local repo của người dùng. Hình 19- Đường dẫn URL của Local Repo Người dùng gõ thẳng đường dẫn của chính file đó để ít ảnh hưởng đến tốc độ của git. Để thêm Local Repo vào một dự án đang thực hiện, người dùng gõ lệnh như sau: Với local_proj là tên Local Repo Ưu điểm: dễ dàng, chỉ cần truy cập một file đã tồn tại được phân quyền và có hỗ trợ mạng internet, dễ dàng chuyển giao công việc cho người bên ngoài nhóm vào làm việc.
25 Nhược điểm: thiết lập truy cập chia sẻ khó khăn đối với môi trường có nhiều nơi cần truy cập, chia sẻ phân vùng không phải cách nhanh nhất, mọi người dùng đều có quyền shell cao nhất nên có thể chỉnh sửa file bên trong hay làm gián đoạn repo. 1.6.2 Giao thức HTTP Git giao tiếp với HTTP qua 2 phương thức, cũ nhất sẽ là Dump HTTP và mới nhất là Smart HTTP. 1.6.2.1 Smart HTTP Giao thức này hoạt động giống như SSH hay những giao thức của git, có cổng HTTPs chuẩn và dùng nhiều phương pháp HTTP chứng thực khác nhau. Sau đây là một vài đặc điểm: - Dễ dàng cho người dùng truy cập bằng phương pháp chứng thực username/password hơn là thiết lập key cho phiên SSH - Là cách để sử dụng git phổ biến nhất hiện nay, có thể phục vụ cho cả giao thức git:// - Có thể đẩy lên bằng phương pháp chứng thực và mã hóa như giao thức SSH, nếu repo yêu cầu chứng thực, server sẽ yêu cầu quyền username/password để truy cập - Phục vụ cả hai phương thức trên chỉ bằng một URL 1.6.2.2 Dump HTTP Nếu server không phản hồi với giao thức Smart HTTP, Git Client sẽ cố gắng sử dụng lại giao thức đơn giản Dump HTTP. Giao thức xem bare git repo như là một tập tin thông thường trên máy chủ web. Giao thức rất dễ cài đặt, người dùng chỉ cần đặt bare git repo trong một thư mục HTTP root và một hook cập nhật cụ thể. Bất cứ thành viên nào có quyền dưới web server đều có thể clone Repository. Để cấp quyền cho Repo bởi giao thức HTTP, chỉ cần vài lệnh sau: Sau đó, để chạy hook cập nhật, người dùng chỉ cần chạy một câu lệnh thích hợp là (git-update-server-info) để khiến git fetch và cloning công việc ngay lập tức, chỉ
26 xảy ra khi người dùng muốn push tới repo đó hoặc muốn clone thứ gì đó như câu lệnh sau: Ưu điểm: - Đơn giản vì chỉ cần một URL cho mọi loại truy cập và có server điều khiển chứng thực khi cần - Có thể chứng thực thông qua username/password giúp người dùng không phải qua thao tác tại key giữ bí mật và đưa key công khai lên server một cách rắc rối - Nhanh và hiệu quả Nhược điểm: - Thiết lập có thể trở nên khó khăn ở vài server so với SSH - Việc cung cấp thông tin đăng nhập đôi khi lại trở nên khó khăn, mặc dù có vài công cụ hỗ trợ đăng nhập với caching 1.6.3 Giao thức SSH Giao thức vận chuyển nổi tiếng của git khi tự hosting chính nó là SSH. Giao thức này được cài đặt ở hầu hết server. Nó đồng thời cũng là một giao thức chứng thực mạng và bởi tính phổ cập của nó nên rất dễ dàng thực hiện thiết lập và sử dụng. Để clone Git Repository thông qua SSH, ta chỉ cần sử dụng URL đặc trưng ssh:// như sau: Người dùng có thể sử dụng cú pháp ngắn gọn hơn như sau: Ưu điểm: - Giao thức phổ biết, dễ dàng cài đặt - SSH daemon lại phổ biến, được nhiều nhà quản trị mạng có kinh nghiệm sử dụng - Được cài sẵn trên nhiều hệ điều hành phân phối và có công cụ để quản lý - Truy cập bảo mật, mọi dữ liệu đều được mã hóa và đã được chứng thực - Ảnh hưởng tích cực đến các giao thức khác như HTTPs, Git và các giao thức Local
27 Nhược điểm: - Không hỗ trợ truy cập ẩn danh vào Git repo - Nếu hệ thống sử dụng SSH, người dùng phải có cài tính năng SSH truy cập vào, không phù hợp với những dự án mã nguồn mở - Khi cài đặt SSH trong hệ thống, chỉ có thể sử dụng nó khi push dữ liệu và phải xài công cụ, giao thức khác để fetch dữ liệu về 1.6.4 Git daemon Được đính kèm với các package cùng git, nó lắng nghe ở cổng mặc định là 9418 cung cấp một dịch vụ giống như giao thức SSH nhưng không có chứng thực. Muốn sử dụng, người dùng phải tạo một file git-daemon-export-ok bởi vì daemon sẽ không phục vụ khi không có file trong đó, tuy nhiên nó lại không được bảo mật. Bất cứ ai tìm thấy địa chỉ URL project của bạn đều có thể push vào đó. Ưu điểm: - Là giao thức internet nhanh nhất - Phù hợp cho nhu cầu có một dự án public hay một dự án lớn không cần phương pháp xác thực - Sử dụng chung phương pháp vận chuyển dữ liệu giống SSH nhưng không mã hóa và xác thực Nhược điểm: - Yếu tố không xác thực - Khó cấu hình thiết lập, yêu cầu phải chạy trên đúng daemon chính nó nên phải cài đặt xinetd hay systemd - Phải chỉnh tường lửa mở cổng mặc định 9418, do không phải là port tiêu chuẩn nên thường bị chặn 1.7 Bài toán dung lượng trong Git Bản thân Git là một hệ thống kiểm soát phiên bản phân tán nên có một nhược điểm là khó quản lý các tệp nhị phân dung lượng lớn do tất cả các hành động Clone lấy về đầy đủ phiên bản, lịch sử của Repo. Bản thân các dữ liệu trong Repo đạt đến dung lượng lớn, trường hợp này người dùng chỉnh sửa file và mỗi lần Commit sẽ lưu lại toàn bộ file trong Repo. Sau vài lần lặp lại, kho lưu trữ cục bộ sẽ nhanh chóng chứa hàng tấn Megabytes và cuối cùng là Gigabytes.
28 Hình 20- Nhiều Commit tăng dung lượng Repo 1.7.1 Git đóng gói Như trường hợp trên, nếu tổng lượng file lớn, nhiều bản Snapshot dẫn tới Git chiếm dụng một lượng lớn bộ nhớ hơn cả VCS. Nhưng Git đã có sẵn một cơ chế khắc phục đó chính là câu lệnh “git gc”, một lệnh duy trì kho, với “gc” viết tắt của bộ sưu tập rác trong Git. Hình 21- Mô tả lệnh git gc Người dùng thực hiện lệnh “git gc”
29 Công dụng của nó như sau: - Nén các đối tượng git được lưu trữ. Khi xác định được một nhóm đối tượng, git sẽ nén chúng thành một gói “pack” - Lưu chúng thành một file giống tệp zip có đuôi .pack nằm trong đường dẫn .git/objects/pack - Xóa những bản chụp có nội dung giống nhau để thu nhỏ kích thước của chính nó để giải phóng không gian ổ đĩa - Không xóa các xác nhận đã tách rời để bảo tồn lịch sử phiên bản và tránh mất dữ liệu Git gc được thực hiện thủ công tương ứng với mức độ hoạt động của một kho lưu trữ, nhất là một kho được đóng góp bởi một nhà phát triển và nó được chạy tự động khi những lệnh sau được thực thi: git pull, git merge, git rebase, git commit. Cấu hình chỉnh sửa lại những giá trị của câu lệnh để làm rõ chức năng của nó: • Thiết lập thời gian lưu trữ các bản ghi trong một nhánh (mặc định là 90 ngày) • Thiết lập thời gian lưu trữ hồ sơ reflog không thể truy cập được (mặc định 30 ngày) • Kiểm soát thời gian dành cho giai đoạn nén delta của việc đóng gói đối tượng (mặc định là 250) khi git sử dụng option [-aggressive] • Kiểm soát độ sâu của việc sử dụng nén khi sử dụng câu lệnh git với tùy chọn [-repack], còn git [-aggressive] thì thực hiện (mặc định là 50)
30 • Đặt thời gian một vật thể không thể tiếp cận sẽ được bảo quản trước khi cắt tỉa (mặc định là 2 tuần trước đó) • Đặt thời gian cho một cây làm việc cũ được bảo tồn trước khi bị xóa (mặc định là 3 tháng) 1.7.2 Git LFS Git LFS (Large File Storage) là một tiện ích mã nguồn mở cung cấp cơ chế xử lý các phiên bản file lớn lưu trữ. Nó có nhiệm vụ thay thế các file lớn như audio, video, dataset hay graphics với con trỏ text bên trong Git, trong khi chứa các file nội dung trên remote Server như Github. LFS không được tích hợp sẵn trong Git, tuy nhiên về phía Server như Github, Gitlab, Bitbucket, công cụ lại được hỗ trợ mạnh mẽ đến nỗi người dùng không cần lo lắng về cách triển khai nó trên Server phức tạp ra sao. Đây là một giải pháp hiệu quả vì LFS hoạt động trong suốt đối với quy mô dự án sẵn có của người dùng, không làm gián đoạn quy trình làm việc dự án. Hình 22- Công cụ Git LFS LFS bao gồm các tính năng: - Chứa phiên bản file lớn: Version Large Files – thậm chí lớn tới gấp đôi kích cỡ GB - Nhiều không gian Repository: lưu trữ file bên ngoài Repo gốc sẽ giúp người dùng giữ kho lưu trữ ở khoảng dung lượng vẫn còn kiểm soát được
31 - Cloning và fetching nhanh hơn: tải về ít dữ liệu hơn – do Repo hiện tại không còn chứa dữ liệu lớn - Quy trình làm việc như Git: không cần bất cứ dòng lệnh nào khác, LFS giống dòng lệnh của Git tạo sự thích nghi nhanh chóng đối với người dùng - Phân quyền và điều khiển truy cập: giữ phân quyền và kiểm soát cho các file lớn giống như các file còn lại của Git Repo khi làm việc với Remote Host Git LFS có cơ chế thay thế tất cả file dung lượng lớn trong Repository bằng những con trỏ tượng trưng nhẹ hơn với vài Bytes. Mỗi con trỏ sẽ tham chiếu đến các file lớn khi chúng được lưu trữ cùng với Repo nhưng nằm bên ngoài vùng Stag. Khi người dùng sử dụng lệnh push, file lớn sẽ được truyền vào nơi chứa LFS (LFS Store được nhúng trong Github) và phần Stag sẽ được truyền vào Repo của Github như thông thường. Repository của người dùng sẽ chỉ nặng thêm vài Bytes khi họ thay đổi một file lớn. Khi người dùng pull để lấy dữ liệu vùng Stag từ Github về như bình thường, sử dụng lệnh commit sẽ thay thế con trỏ thành chính file lớn liên quan tham chiếu từ nơi chứa LFS. Điều đó thể hiện người dùng chỉ tải về phiên bản các file mà họ muốn làm việc cùng chứ không phải mỗi phiên bản như trước. Lập trình viên khi làm việc với LFS không thấy những file con trỏ trên ổ đĩa của họ vì Git LFS sẽ tự động ngắt khỏi vùng Staging khi nhận thấy sự thay đổi của dữ liệu hoặc khi lập trình viên quay lại lệnh commit trước đó. Người lập trình không cần phải học thêm bất cứ câu lệnh nào khác từ Git LFS.
32 CHƯƠNG 2: CÀI ĐẶT GIT 2.1 Các môi trường Git hỗ trợ Git hỗ trợ nhiều nền tảng, có cả 3 nền tảng phổ biến với người dùng: Windows, Linux, MacOS. Do không có thiết bị chạy hệ điều hành MacOS, nhóm xin thực hiện demo các bước cài đặt trên 2 nền tảng còn lại là Windows và Linux. Người dùng tải file cài đặt hoặc clone Source Code từ trang web chính thức của Git cho 3 nền tảng qua đường dẫn sau: https://git-scm.com/downloads Hình 23- Website tải Git chính thức của nhà phát hành 2.1.1 Trên Linux Hệ điều hành Linux hỗ trợ Git rất tốt, đặc biệt là với công cụ Terminal mặc định của Linux, giúp Git phát huy được tối đa sức mạnh vốn có. Git sẽ có nhiều cách cài khác nhau dựa trên từng Distro từ nhân Linux. Người dùng cần truy cập vào trang chủ của Git, làm theo hướng dẫn với đường dẫn sau: https://git- scm.com/download/linux Bước 1: Mở terminal và gõ 2 lệnh sau Bước 2: Gõ lệnh ‘git –version’ để kiểm tra đã cài đặt thành công
33 2.1.2 Trên Windows Windows vốn là hệ điều hành quen thuộc với đại đa số người dùng. Việc Git hỗ trợ cho hệ điều hành quốc dân này tạo nhiều điều kiện đa dạng cho người dùng, nhất là lập trình viên chọn lựa làm việc trên hệ điều hành họ thích. Để cài Git trên Windows, người dùng cài công cụ giả lập Terminal. Bước 1: Truy cập vào đường dẫn https://gitforwindows.org/ Hoặc tải từ trang chủ: https://git-scm.com/download/win Bước 2: Tải xuống một file *.exe, nhấn chuột vào file để tiến hành cài đặt
34 Bước 3: Cài đặt bình thường như các phần mềm khác có hỗ trợ giao diện cho Windows, dựa vào yêu cầu của mỗi người dùng mà chọn lựa cho phù hợp Bước 4: Bước tiếp theo là cài git editor cho windows, có thể là các text editor như vim, notepad++, sublime text,… Hình 24- Lựa chọn Sublime Text làm Git Editor Bước 5: Tiếp theo, lựa PATH môi trường thích hợp với nhu cầu
35 Bước 6: Chọn phong cách dòng lệnh như thế nào Bước 7: Bấm install để cài đặt
36 Bước 8: Cài đặt thành công Bước 9: Gõ lệnh git version để kiểm tra phiên bản cũng như Git đã cài đặt thành công
37 Sau khi cài đặt, do tùy chọn ở bước 5, công cụ Git sẽ xuất hiện hai tệp chạy chương trình, mỗi tệp ứng với một môi trường. Tệp git-bash sẽ dành cho người dùng quen thuộc với hệ thống kiến trúc hệ điều hành Unix/Linux. Tệp git-cmd còn lại phù hợp cho những người dùng quen thuộc với MS – Dos, vốn là các lệnh được tích hợp trong Command Prompt (CMD) của hệ điều hành Windows. Hình 25- Hai chương trình khởi chạy ứng với hai môi trường 2.1.3 Phiên bản GUI Ngoài ra, người dùng còn có thể tải về phiên bản Graphical User Interface (GUI) dành cho Git, hỗ trợ trên cả 3 nền tảng cung cấp giao diện để người dùng thao tác dễ dàng, giúp họ không gặp khó khăn với vấn đề học cách sử dụng dòng lệnh Sẽ có rất nhiều phiên bản GUI bao gồm miễn phí, trả phí, tích hợp tính năng khác để phục vụ tốt hơn. Truy cập đường dẫn sau để tải về phiên bản giao diện của Git: https://git-scm.com/download/gui/windows Hình 26- Công cụ bên thứ 3 hỗ trợ GUI cho Git
38 CHƯƠNG 3: TRIỂN KHAI 3.1 Cấu hình Github Để tương tác sử dụng Git trong các công việc, dự án về Code, sau đó đưa nó lên các kho lưu trữ Code như Github, Gitlab…. Ở đây, liên quan đến tên đề tài, nhóm em lựa chọn Github để thực hiện. Muốn sử dụng Github, điều đầu tiên yêu cầu mỗi người dùng là tạo một tài khoản sử dụng. Github hỗ trợ tính năng này miễn phí và dễ dàng cho nhiều người tiếp cận. Người dùng điền đầy đủ thông tin rồi nhận Mail kích hoạt. Hình 27- Nơi đăng ký tài khoản Github Sau khi kích hoạt tài khoản thành công, người dùng sẽ được tương tác trực quan qua giao diện Web với kho lưu trữ Github như tạo Repo dự án ban đầu, chia nhánh và phối hợp với Git như một Server. 3.1.1 Tạo Github Repository Để làm việc, trước hết cần tạo một kho lưu trữ mã nguồn lệnh cho dự án, việc này về bản chất cũng giống như thao tác trên các dòng lệnh Git, ở đây, người dùng sẽ làm qua giao diện với các cú nhấp chuột. Các bước tạo Repo ban đầu được mô tả như sau:
39 Bước 1: Người dùng bấm vào ký hiệu dấu cộng bên cạnh ảnh đại diện của tài khoản và chọn New repository, Github sẽ chuyển qua trang khởi tạo Repo mới Hình 28- Khởi tạo Github Repositories Bước 2: Đặt tên cho Repo cũng như miêu tả dự án nếu cần thiết Hình 29- Đặt tên cho Repo Hình 30- Mô tả Repo dự án Bước 3: Chọn một trong hai tùy chọn do Github đưa ra. Hai tùy chọn có nội dung như sau: - Hai chế độ phân quyền là Public và Private. Public là chế độ mặc định, cho phép bất cứ ai cũng có thể xem được Repo. Nếu người tạo không muốn công khai có thể chuyển sang chế độ Private Hình 31- Hai chế độ phân quyền của Repo Github
40 - Tập tin README giới thiệu Repo kèm một tập tin .gitignore. Đây là một template có sẵn trong Github và cho mọi người tùy chọn Hình 32- Template tùy chọn Repo Github Bước 4: Bấm nút Create repository tạo Repo, Github sẽ chuyển trang Repo đã hoàn thành *Trường hợp, người dùng không thêm tùy chọn, Github sẽ mặc định đây là người dùng mới với dịch vụ nên nó sẽ chuyển đến một trang hướng dẫn cho người dùng này.
41 Khi đã có Repository, người dùng có thể clone, pull, push… mã nguồn lệnh dự án của mình lên đó. Phần tiếp theo, nhóm em sẽ tìm hiểu về Branch trên Github. 3.1.2 Tạo Github Branch Nguyên nhân ra đời cũng như tổng quát về Branch (nhánh) sẽ được nhóm giải thích chi tiết ở nội dung “Cấu hình Git nâng cao”. Ở Github, việc tạo nhánh trải qua hai bước đơn giản. Bước 1: Người dùng chọn vào mũi tên trỏ xuống tại mục Branch trên giao diện Web Bước 2: Đặt tên Branch để hiển thị nút tạo Hình 33- Đặt tên nhánh trên Github Bước 3: Ấn tạo bằng dòng Create branch: [tên_nhánh], kết quả là nhánh tạo thành công
42 Hình 34- Repo hiện có 2 nhánh 3.1.3 Sử dụng Github Github có đầy đủ dòng lệnh của Git, do yêu cầu đề tài chuyên sâu về Git nên nội dung phần này sẽ chỉ bao quanh 3 câu lệnh cấu hình Github cơ bản nhất. Ba câu lệnh mô tả cả một quy trình làm việc của Github. Các câu lệnh khác sẽ được đề cập cụ thể trong các phần cấu hình Git. 3.1.3.1 Lệnh Commit trên Github Câu lệnh Commit cho phép lưu lại thay đổi của file cùng tin nhắn mô tả rõ ràng cho phép quản lý, theo dõi dự án tốt hơn. Để commit, người dùng làm như sau: Bước 1: Chọn file muốn sửa Bước 2: Nhấn ký hiệu Edit để sửa file Bước 3: Sửa nội dung file “Day la danh cho muc dich hoc tap!!” Bước 4: Để lại lời nhắn và nhấn Commit changes
43 3.1.3.2 Lệnh Pull trên Github Câu lệnh quan trọng trên Github, cho biết những thay đổi trong Source Code, yêu cầu chủ sở hữu xem xét, hỗ trợ mọi người đóng góp công sức vào dự án. Tránh sự nhầm lẫn về lệnh Pull, nhóm sẽ làm rõ hơn câu lệnh này: - Lệnh Pull Request: yêu cầu chủ sở hữu xem xét thay đổi trước khi gộp vào nhánh chính - Lệnh Pull: lệnh đơn thuần của Git để nâng cấp dữ liệu từ server về Local, có thể xảy ra xung đột Bước 1: Vào tab Pull requests và nhấn New pull request Bước 2: Chọn file cần thiết Bước 3: Xem sự khác nhau giữa hai lần commit
44 Bước 4: Bấm tạo Create pull request và hoàn thành câu lệnh Hình 35- Tạo pull request trên Github 3.1.3.3 Lệnh Merge trên Github Lệnh hợp nhất các nhánh trên Github trải qua các bước sau: Bước 1: Bấm nút Merge pull request để hợp nhất những thay đổi vào nhánh Master Bước 2: Xác nhận gộp nhánh Master và hoàn thành Bước 3: Github đưa ra tùy chọn xóa nhánh sau khi gộp thành công
45 3.1.4 Xóa Github Repository Nếu có nhu cầu xóa Repo thì yêu cầu tài khoản người dùng phải có đặc quyền hoặc là Admin cho một Repo của tổ chức. Các bước xóa Repo trên Github rất đơn giản nhưng có một vài điều cần lưu ý là tất cả các tệp đính kèm cùng phân quyền nhóm dự án đều bị xóa bỏ. Người dùng có thể khôi phục lại hành động xóa Repo trong 90 ngày. Bước 1: Quay lại trang chính của Repo cần xóa, nhấp vào biểu tượng Settings Bước 2: Kéo đến mục Danger Zone, bấm nút xóa Repo ở mục cuối cùng Bước 3: Đọc bảng cảnh báo của Github, nhập chính xác tên Repo bạn muốn xóa Bước 4: Nhấn đồng ý lời khẳng định sẽ chịu trách nhiệm cho hành động này để xóa Repo Bước 5: Nhập mật khẩu để khẳng định lại lần nữa và xóa Repo thành công
46 Hình 36- Repo trên Github đã xóa 3.2 Cấu hình Git cơ bản Nhằm minh họa trực quan cách hoạt động của các lệnh Git cơ bản, nhóm đã thực hiện hai video quay lại quá trình sử dụng Git trên cả hai hệ điều hành. Các bước làm vẫn sẽ được trình bày đầy đủ bên dưới. - Link video trên Windows: https://youtu.be/4tJE4fUrL6U - Link video trên Linux: https://youtu.be/XVNO_Rml1Dk 3.2.1 Thiết lập ban đầu Điều đầu tiên cần làm sau khi cài đặt git là cấu hình chứng thực, thiết lập các tùy chọn ban đầu phù hợp với cá nhân người sử dụng. Những thông số cấu hình này nên chỉ làm một lần trên mỗi máy tính và nó sẽ không thay đổi kể cả người dùng có nâng cấp git. Họ có thể thay đổi các thông số cấu hình bằng cách sử dụng lại câu lệnh cấu hình. Git có một công cụ dòng lệnh là git config để cho người dùng tùy chỉnh các giá trị để git có giao diện và vận hành như họ muốn. Các giá trị có thể được chứa ở ba nơi khác nhau, muốn xác định người dùng cần gõ lệnh git config –list –show-origin, nó sẽ hiển thị file config được lưu trên đường dẫn nào, cũng như các giá trị đã được cấu hình mặc định bởi Git.
47 Hình 37- Xem thông số mặc định 3.2.1.1 Định danh Người dùng khai báo tên và địa chỉ mail trong file cấu hình Git. Điều này rất quan trọng vì Git sẽ dùng thông tin này trong lúc người dùng thực hiện lệnh commit (sẽ được nhắc đến sau). Họ chỉ cần 2 câu lệnh đơn giản như sau: Người dùng chỉ cần làm một lần động tác này với tùy chọn [--global], các đợt sau nếu muốn chuyển đổi cho một dự án nào đó, họ chỉ cần gõ lại lệnh này mà không cần tùy chọn trên. Nếu họ sử dụng công cụ có giao diện thì bản thân công cụ đó sẽ tạo sẵn cho người dùng 3.2.1.2 Kiểm tra cài đặt Git sẽ đọc một giá trị đến từ các file khác nhau, người dùng gõ lệnh git config – list để liệt kê các thiết lập mà Git tìm thấy.
48 Người dùng còn có thể kiểm tra những giá trị đặc trưng bằng lệnh git config <key> với tùy chọn “key” là thuộc tính như user, filter, core…. Hình 38- Xem xét tham số name thuộc User 3.2.1.3 Trợ giúp Hình 39- Website tập hợp các lệnh config Hình 40- Các lệnh config Git Người dùng có thể sử dụng các gợi ý trợ giúp được tích hợp sẵn trong công cụ là [--help] hoặc [-h], để sử dụng các lệnh [config] chỉnh sửa các thiết lập. Git sẽ hiển thị một trang web có các lệnh hướng dẫn cấu hình khi người dùng xài lệnh git help config.
49 Đôi lúc, người dùng chỉ cần trợ giúp ở một câu lệnh cụ thể, họ sẽ gõ git <tùy_chọn> -h với “h” chính là viết tắt của từ Help. Hình 41- Xem trợ giúp lệnh commit 3.2.2 Các lệnh cơ bản 3.2.2.1 Khởi tạo Git Repository ban đầu Mục đích tạo ra một thư mục lưu trữ trong Git để chứa những dữ liệu cần thiết của một dự án, mỗi thành viên, đặc biệt là người quản trị phải thực hiện những động tác sau: Bước 1: Tại Local, thành viên quản trị mở ứng dụng Git Bash cho Windows đi vào một đường dẫn để chứa dự án Hình 42- Tạo một thư mục chứa tập tin Bước 2: Tạo file dự án để thao tác
50 Hình 43- Tạo file dự án Bước 3: Người quản trị nhập nội dung cho file dự án Bước 4: Người quản trị nhập lệnh cấu hình file dự án - Sử dụng lệnh git init để khởi tạo một Repo tại đường dẫn đó - Gõ lệnh git status để xem tình trạng hiện tại của Repo, file index vẫn chưa vào vùng Staging - Gõ lệnh git add [file] thêm file index vào vùng Staging và kiểm tra lại trạng thái
51 - Để đưa file index ra khỏi vùng Staging, người quản trị gõ lệnh git rm –cached [file] - Sử dụng lệnh commit file để chụp lại trạng thái hiện tại, thêm thông điệp đính kèm (bắt buộc) để thông báo cho thành viên khác về mục đích Snapshot - Thêm đường dẫn HTTPs của Remote Repository mà người quản trị ban đầu, xài lệnh git push để đưa file lên server phục vụ cho mục đích làm việc từ xa cho các nhân viên
52 - Gõ lệnh git log để xem những hành động đã làm - Tải lại trang Web Github để kiểm tra file index trên Remote server 3.2.2.2 Cách Clone dự án bằng Git Khi đưa lên Remote Server, phía thành viên trong dự án sẽ clone dữ liệu về, rồi làm việc trong dữ liệu đó, làm theo yêu cầu cấp trên rồi đẩy dữ liệu đó lên lại Server. Có 2 cách để làm việc này, đó là sử dụng nút bấm trên Github hoặc sử dụng lệnh git clone của Git. - Trường hợp 1: Người dùng chọn tải trực diện về toàn bộ dự án trong định dạng file .zip thông qua giao thức HTTPs bằng cách nhấn mở xuống khung Code hoặc có thể bằng phần mềm Desktop của Github
53 Hình 44- Tải Github Repo bằng file zip - Trường hợp 2: Clone bằng câu lệnh Git được mô tả các bước như sau Bước 1: Người quản trị thêm các thành viên vào Repo trên Github Bước 2: Cấp quyền cho từng tài khoản quyền tương ứng Bước 3: Thành viên sử dụng lệnh git clone cùng với địa chỉ URL của Repo muốn lấy về trên Github rồi thực hiện.
54 Hình 45- Lấy về toàn bộ dự án Trong quá trình làm việc, thành viên muốn tương tác với nhóm và Server có thể xài các lệnh cơ bản như add, commit, push và pull. 3.3 Kết nối Git đến Github qua SSH 3.3.1 Khái niệm SSH SSH (Secure Shell) là một giao thức mạng dùng để thiết lập kết nối mạng một cách bảo mật. Khi làm việc với Git, SSH sẽ giúp ta trong 2 việc: - Bảo mật các kết nối của mình với server. - Không phải nhập mật khẩu mỗi lần push Code 3.3.2 Cơ chế làm việc SSH Người dùng sở hữu 2 Key (khóa): Public Key (khóa công khai) và Private Key (khóa bí mật). Public Key sẽ được lưu trữ trên Server của Git (Github là một ví dụ). SSH - agent đóng vai trò làm tất cả những việc còn lại cho bạn. Mỗi lần bạn push, SSH - agent sẽ tự gửi kèm theo các thông tin chứng thực, Github sẽ nhận diện ra bạn, và bạn không cần phải nhập mật khẩu nữa. Một điều lưu ý là Github quy định mỗi SSH Key chỉ được gắn với một tài khoản. 3.3.3 Các bước tạo khóa và kết nối Github Bước 1: Tạo khóa, mở cmd (Command Line) chạy với quyền quản trị hoặc mở Git Bash gõ câu lệnh ssh-keygen -t rsa -C “<tên email của bạn Github>”
55 Khi chạy câu lệnh,hệ thống sẽ hỏi bạn muốn lưu khóa ở đâu,mặc định sẽ lưu trong đường dẫn trên ../.ssh/id_rsa. Nếu đồng ý nhấn Enter. Tiếp theo đoạn mã tạo khóa sẽ mời nhập mật khẩu (Passpharse), nếu để trống nhấn Enter còn đặt mật khẩu, ta sẽ đặt mật khẩu của tài khoản Github Sau khi nhập mật khẩu xong sẽ ra kết quả như sau: Bạn có thể lưu giữ file ida_rsa (khóa bí mật) trong Keychain khi thêm nó vào SSH – agent. Khởi tạo SSH – agent bằng dòng lệnh eval $(ssh-agent –s) như trong hình. Hình 46- Thêm khóa bí mật vào SSH - agent Bước 2: Kiểm tra khóa Để mở file có chứa khóa vừa tạo, gõ câu lệnh cat ~/.ssh/id_rsa.pub với đuôi *.pub là định dạng của Public Key.
56 Hình 47- Nội dung khóa công khai Sao chép khóa vừa tạo như hình trên. Bước 3: Kết nối Vào Github.com chọn Setting sau đó chọn SSH and GPG keys. Sau đó chọn New SSH key Màn hình sẽ hiện ra bảng sau:
57 Phần Title là tiêu đề có thể đặt tùy thích. Phần Key là khóa vừa sao chép trong mục id_rsa.pub dán vào ô Key. Sau đó nhấn Add SSH key để thêm khóa vừa tạo. Bước 4: Kiểm tra Thử sao chép một Repo về máy Thiết lập kết nối Git với Github thông qua giao thức SSH, tạo chứng thực thông tin người dùng thành công
58 3.4 Cấu hình Git nâng cao Với các lệnh nâng cao của Git, nhóm em sẽ tập trung vào tìm hiểu tính năng nhánh trong Git, cách phân nhánh, gộp nhánh, đồng thời tìm ra các giải pháp khắc phục xung đột lúc phân nhánh hay thời khắc đẩy tập tin lên Repository. 3.4.1 Nhánh là gì, tại sao phải phân nhánh Nhánh trong Git cũng giống như một cái cây có thân chính là nhánh Master trong Git, từ nhánh chính này phát triển thành nhiều nhánh con, từ những nhánh con này đều phát triển “hoa”, “lá” và đều được gắn liền với nhánh chính. Các nhánh này đều có chung mục đích là làm cho cây của mục thêm phần sinh động và đẹp hơn. Git lúc đầu có nhánh gốc là nhánh Master. Câu chuyện được đặt ra là một thành viên muốn thêm một tính năng cho dự án có sẵn, nhưng phần chỉnh sửa lại dễ ảnh hưởng đến dự án chính. Branch ra đời. Tính năng một nhánh Master gốc thành nhiều bản sao của cùng một Repository, cho phép người dùng chuyển đổi qua lại giữa các trạng thái và phiên bản khác nhau. Từ những nhánh con đã phân tách, những người tham gia dự án có thể chỉnh sửa, thêm xóa chương trình của mình hợp lý, có thể kiểm tra quá trình hoạt động dự án ngay trên nhánh của mình mà không ảnh hưởng đến nhóm chính. Khi mọi sự hoàn tất người tham gia dự án có thể gộp nhánh của mình với nhánh chính cùng những tính năng mới để hoàn thiện dự án. Hình 48- Quy trình chia nhánh
59 3.4.2 Tạo nhánh Bước 1: Kiểm tra nhánh Chỉ có 1 nhánh Master (nhánh gốc) Bước 2: Phân nhánh Dùng lệnh git branch+<Tên nhánh> Bước 3: Kiểm tra nhánh đã tạo Như vậy nhánh b1 đã tạo thành công. 3.4.3 Phân nhánh Bước 1: Dùng lệnh git checkout +<tên nhánh chuyển> Bước 2: Kiểm tra nhánh người dùng đang truy cập Dùng lệnh git branch Dấu sao trước tên nhánh cho biêt vị trí nhánh hiện tại
60 3.4.4 Gộp nhánh Bước 1: Chuyển nhánh Chuyển sang nhánh b1 Bước 2: Tạo file text có tên “nhanh.txt” Tiến hành nhập thông tin file text sau khi nhấn enter tạo file text. Để lưu lại và thoát nhấn tổ hợp phím ctrl+D. Kết quả được hiển thị như hình dưới: Bước 3: Thêm file “nhanh.txt”vào nhánh b1 Bước 4: Ghi chú Bước 5: Kiểm tra Lệnh ls dùng kiểm tra file hiện có nhánh b1 Kiểm tra nhánh Master
61 Bước 6: Tiến hành gộp nhánh b1 vào nhánh Master Đầu tiên chuyển sang nhánh Master Tiến hành gộp nhánh b1 bằng lệnh git merge đối với b1 Tiếp theo kiểm tra các file nhánh Master Đã xuất hiện tên file “nhanh.txt” là file vừa tạo bên nhánh b1. 3.4.5 Xóa nhánh Bước 1: Chuyển sang nhánh Master Bước 2: Xóa nhánh b1 Dùng lệnh git branch -d +<tên nhánh xóa>
62 Bước 3: Kiểm tra Dùng lệnh git branch để xem nhánh hiện có Chỉ còn nhánh gốc là Master 3.5 Giải quyết xung đột trên Git Do cơ chế tự động tích hợp những gì thay đổi trong git, qua những thao tác push, pull, merge dòng lệnh không ít thì nhiều cũng phát sinh lỗi như trường hợp xung đột dòng lệnh, file dạng text “conflict” trên cấp độ file hoặc là nhánh. Xung đột chỉ ảnh hưởng đến nhà phát triển trong quá trình hợp nhất, những người còn lại không tham gia vào quá trình thay đổi file sẽ không biết gì về xung đột. Nguyên tác đưa ra là ai gây ra xung đột, người đó tự giải quyết. Nội dung mục này sẽ nói về các cách giải quyết xung đột theo hai trường hợp trong Git. 3.5.1 Xung đột tập tin trong một nhánh Để giải quyết xung đột tập tin, người quản trị cần làm những điều sau: Bước 1: Đưa file lên Remote Repo bằng lệnh git push Bước 2: Xem một file upload.txt có nội dung như sau
63 Bước 3: Một thành viên chỉnh sửa file ở dòng “First page” rồi lưu lại bằng nút “Commit Change” Bước 4: Một thành viên còn lại chỉnh sửa file ở phía Local mà không hay biết việc file đã bị chỉnh sửa trên server Bước 5: Thành viên này sử dụng các lệnh add, commit, push để đưa file lên Remote
64 Bước 6: Git thông báo lỗi tới người dùng, gợi ý sử dụng lệnh git pull để kéo dữ liệu về kiểm tra, Git sau đó sẽ hiện ra chi tiết lỗi cụ thể cho người dùng Bước 7: Thành viên tại Local xóa nội dung xung đột, giữ lại nội dung cần thiết cho dự án Bước 8: Sử dụng lại các lệnh đưa dữ liệu lên Remote server
65 Bước 9: Kiểm tra trên Github 3.5.2 Xung đột tập tin trong nhiều nhánh Trong một dự án bao gồm nhiều nhánh, mỗi nhân viên làm việc trên một nhánh. Khi xong phần công việc của mình, nhân viên gộp phụ của mình vào nhánh chính để hoàn thiện dự án. Tuy nhiên, trường hợp nhánh phụ có nhiều Commit kể từ thời điểm rẽ nhánh, khi gộp vào nó sẽ xem xét sự thay đổi trên các nhánh. Nhận thấy sự giống nhau về nội dung trên một dòng của từ 2 file trở lên, Git sẽ thông báo xung đột nhánh. Để giải quyết tình trạng này, nhóm em mô phỏng lại quá trình gộp nhánh trên 2 nhánh có sẵn là Master và Alpha, xảy ra xung đột qua các bước sau: Bước 1: Kiểm tra hai nhánh hiện có
66 Cả 2 nhánh đều có nhiều Commit kể từ thời điểm rẽ nhánh Khi gộp Git sẽ xem xét trên 3 thời điểm, thời điểm commit cuối của các nhánh và thời điểm rẽ nhánh, đó lần lượt là commit với các Snapshot C2, C4, C7 (các Commit này được nhóm làm từ trước). Hình 49- Rẽ nhánh tại Snapshot C2 Bước 2: Trở về thời điểm Snapshot C2 (có mã Hash là 1b136f7), thời điểm rẽ nhánh từ Master ra Alpha bằng lệnh git checkout tạo ra một nhánh tạm để HEAD trỏ vào C2
67 Bước 3: Mở thư mục làm việc sẽ thấy có 3 file với nội dung trống bên trong Bước 4: Kiểm tra nhánh Alpha với Commit cuối ở Snapshot C4 Trong thư mục làm có 4 file, chỉ duy nhất file 1.txt có nội dung Bước 5: Kiểm tra nhánh Master tại Commit cuối ở C7 Trong thư mục lúc này có duy nhất file 4.txt có nội dung rỗng, các file còn lại đều có nội dung. Điểm đặc biệt cần lưu ý ở file 1.txt có một nội dung khác với nội dung chính nó ở nhánh Alpha Nguyên nhân gây xung đột chính là nội dung của file 1.txt nếu gộp nhánh Alpha vào Master, Git không biết chọn giữ lại bản nội dung nào của file 1.txt. Bước 6: Gộp nhánh Alpha vào Master để thấy rõ sự xung đột
68 Git vẫn đang trong quá trình Merge nhưng chờ xử lý xung đột của file 1.txt. Git không tạo Commit mới cho tới khi nào hết xung đột. Kiểm tra lại trạng thái, ta thấy được 3.txt đã có sẵn trong vùng Stag nhưng file 1.txt lại chưa được gộp. Bước 7: Xử lý xung đột thủ công bằng cách mở file xung đột (ở đây là 1.txt) và xóa nội dung ta cần xóa Hình 50- Hai nội dung xung đột gộp nhánh Nội dung nằm giữa <<<<<<< HEAD và ======= là nội dung từ Master, từ ======= và >>>>>>> alpha là nội dung từ Alpha. Chọn phần nội dung cần xóa là của Alpha, Sau khi hết xung đột, Git tự động gộp xong nhánh. Hình 51- Giữ lại nội dung của Master
69 Bước 8: Tiến hành đưa file vào vùng Stage và tạo ra Commit cùng thông điệp “C8” để hoàn thành việc gộp nhánh Bước 9: Xem lịch sử Commit của cả hai nhánh bằng lệnh git log Hình 52- Lịch sử Commit trên Alpha Hình 53- Lịch sử Commit trên Master Biểu diễn các lịch sử Snapshot theo hình sau khi gộp nhánh Để giải quyết xung đột trong Git, cách đơn giản là chỉnh sửa nội dung trên file dẫn tới xung đột, sau đó cho nó vào Stag và chỉnh sửa trong đó. Một số gợi ý được đưa ra
70 để giảm thiểu sự xung đột, đặt biệt là trong một dự án có quá nhiều thành viên cùng thực hiện chỉnh sửa file. - Xác định một quy trình làm việc ngay từ đầu cho các thành viên trong một dự án - Cam kết thường xuyên đẩy những tập lệnh nhỏ, nếu có xung đột sẽ dễ giải quyết hơn việc một lượng lớn các tập lệnh được đẩy đến kho lưu trữ từ xa (Remote Repo) của Git - Nên kéo (pull) các thay đổi từ kho lưu trữ từ xa Git trước khi làm việc trên các tập lệnh mới và trước khi commit - Mỗi thành viên nên làm việc trên từng tính năng trên các nhánh riêng biệt tại cùng một thời điểm 3.6 Cài đặt, cấu hình Git LFS 3.6.1 Cài đặt Git LFS Người dùng có nhu cầu sử dụng công cụ Git LFS để quản lý Repository có các file dung lượng lớn hoạt động trơn tru có thể tham khảo ở trang chủ qua đường dẫn https://git-lfs.github.com/ và tải về phiên bản công cụ LFS phù hợp cho hệ điều hành đang sử dụng. Hình 54- Trang chủ tải Git LFS cho Windows Việc cài đặt sẽ trải qua 2 bước đơn giản như sau:
71 Bước 1: Tới đường dẫn chứa file cài vừa tải nhấn chuột hai lần để Windows để thiết lập bảng cài đặt Git LFS Bước 2: Mở Git Bash, gõ lệnh git lfs install và xác nhận Git LFS cài thành công *Công cụ Git LFS được cài đặt sẵn trong Git Bash nên các bước trên sẽ mô phỏng quy trình cài đặt cho trường hợp không tìm thấy LFS khi cần sử dụng công cụ. 3.6.2 Cấu hình Git LFS Giả sử người dùng có một Repo đã liên kết với Remote Repo trên Github, với 2 câu lệnh dưới cho thấy file .git Repo có dung lượng rất nhẹ với 77 Kbyte. Yêu cầu đối với Repo này là phải bao gồm thêm các file dung lượng lớn để phù hợp với kế hoạch của dự án, trải qua các bước sau: Bước 1: Thêm 3 file có dung lượng khá lớn lần lượt từ 1 mb, 10mb đến 100 mb, đẩy nó lên Repository Origin của Github để khám phá công cụ LFS Bước 2: Kiểm tra lại bằng lệnh git status thấy được một file ở dạng Untracked chính là file chứa 3 file dung lượng lớn
72 Bước 3: Khởi tạo Repo để cài đặt Git LFS, áp dụng các thiết lập của LFS vào Repo hiện hành, gõ lệnh git lfs install Bước 4: Cho LFS biết loại định dạng file người dùng cần theo dõi trong dự án, file ví dụ có đuôi là *.file, nó sẽ thông báo người dùng file đang được theo dõi Câu lệnh này sửa đổi file .gitattributes của kho lưu trữ Repo và liên kết các tệp lớn với Git LFS Bước 5: Thêm nội dung của đường dẫn vào Repo Bước 6: Bật trạng thái xem dữ liệu đã được thêm vào Repo Ta có thể xem tổng dung lượng lúc này của file .git Repo đã tăng lên đáng kể
73 Tất cả các file được đặt dưới một đường dẫn thư mục mới tên lfs. Đường dẫn này sẽ không đồng hành cùng Repo trong việc xài lệnh add, checkout Bước 7: Thêm file .gitattributes vào Index để nó song hành cùng Repo Bước 8: Thực hiện commit file lớn này Chỉnh sửa thông điệp cho Commit này Bước 9: Tạo một nhánh riêng để quản lý rồi đẩy lên Github Remote Origin
74 Bước 10: Push nhánh này với nội dung các file lớn tới Remote Repo, tùy vào tốc độ mạng, nhánh sẽ push nhanh hơn Nhánh đã xuất hiện ở Remote Origin để mọi người có thể kéo dữ liệu về sử dụng Việc lấy dữ liệu về lúc này khá dễ dàng vì dữ liệu được lấy về là dữ liệu cần thiết chứ không phải toàn bộ phiên bản như trước khi xài Git LFS. Điều này được minh họa qua các bước sau. Bước 1: Xài lệnh git clone để lấy lại dữ liệu file lớn và bỏ vào một đường dẫn khác Bước 2: Xem tổng dung lượng của file .git
75 Khi sử dụng lệnh Clone thì nhánh mặc định của ta là nhánh Master, kiểm tra trạng thái để thấy nhánh chứa file dung lượng lớn Bước 3: Xài lệnh checkout để chuyển sang nhánh quản lý file dung lượng lớn và xem chuyện gì xảy ra Git Hooks (tính năng can thiệp vào thông số của Git bằng những đoạn lệnh ngẫu nhiên) cho lệnh Checkout bắt lấy các file dữ liệu lớn và ta có thể kiểm tra lại dung lượng file .git lúc này đã tăng lên. Tất cả dữ liệu tải về được bỏ vào đường dẫn file lfs Một điều tuyệt vời nữa là người dùng có thể chuyển nhánh thoải mái, Git LFS sẽ không thêm bất cứ file nào ảnh hưởng đến nhánh khác
76 Git LFS chỉ lưu trữ (cached) các file lớn được cho phép theo dõi trong thư mục đường dẫn lfs và lấy lại file đó. 3.7 Tích hợp với hệ thống SVN Một doanh nghiệp làm việc luôn triển khai một hệ thống nhanh chóng, rồi duy trì hệ thống đó đảm bảo sự ổn định cho công việc. Đó là nguyên nhân việc chuyển giao hệ thống luôn là vấn đề nan giải. Một doanh nghiệp có một dự án trên VCS không thể chuyển sang Git ngay lập tức, họ sẽ phải sử dụng nhiều cách để thực hiện điều đó. Git có những tính năng tuyệt vời, đóng vai trò làm client, hỗ trợ cho việc chuyển giao giữa các VCS như Subversion, Perforce, Bazaar, TFS…. Một trong những tính năng đó được gọi là cầu “bridge” thông qua các dữ án sử dụng VCS khác. Do mục đích yêu cầu đề tài, nhóm sẽ chỉ tập trung vào cách triển khai chuyển đổi kho code từ SVN sang git. 3.7.1 Giới thiệu SVN2Git SVN là một cái tên điển hình trong mô hình CVCS, nó đã trụ vững suốt một thập kỉ. Một phần lớn các dự án phát triển mã nguồn mở và một số lượng lớn các dự án doanh nghiệp sử dụng Subversion để quản lý mã nguồn của họ. Muốn chuyển đổi kho dữ liệu từ SVN sang Git một cách bán phần, git sử dụng tính năng cầu hai chiều “bidirectional bridge” gọi là Git SVN. Công cụ này mang lại nhiều sự tiện lợi cho cả hai bên. - Cho phép người dùng sử dụng git như là một client hợp pháp đối với Subversion server - Hỗ trợ các tính năng tại local của git, sau đó có thể push dữ liệu đó lên Subversion server - Có thể chia, gộp nhánh, sử dụng khu vực staging, dùng rebase - Một cách gián tiếp giúp các lập trình viên làm việc hiệu quả trong lúc chủ doanh nghiệp tìm kiếm giải pháp chuyển đổi hoàn toàn sang git
77 Git ở đây sẽ đóng vai trò như client đối với server Subversion, thay thế các Subversion client khác nhau TortoiseSVN hay công cụ tích hợp trong Eclipse. Hình 55- Mô hình sử dụng Subversion clients Việc ra mắt công cụ này được xem là một liều thuốc mở rộng đối với mô hình DVCS vốn đang bị hạn chế. 3.7.2 Cấu hình Git – SVN Điều đầu tiên người dùng cần là một SVN repository thông thường và họ có quyền write lên nó nên họ cần cài đặt SVN. Do để thỏa yêu cầu đề tài nên toàn bộ quá trình cài đặt SVN sẽ được tóm gọn thông qua các trang web hướng dẫn sau: - Cài đặt trên Linux: https://www.linuxcloudvps.com/blog/how-to-install-svn- server-on-debian-9/ - Cài đặt trên Windows (VisualSVN): https://o7planning.org/vi/10207/huong- dan-cai-dat-va-quan-ly-visual-svn-server VisualSVN là một sản phẩm của Microsoft sử dụng như một Repository server, có bản trả phí và miễn phí, lưu trữ các file chia sẻ giữa các thành viên trong nhóm. Các thành viên sẽ cài đặt chương trình Subversion miễn phí để giao tiếp với server. Thiết lập chuyển kho code, người dùng cần tạo một SVN Repo có phân quyền. Muốn làm được điều đó, trước tiên, họ phải dựng được một server có cài sẵn Subversion. Do SVN yêu cầu mỗi người dùng phải có một tài khoản để ghi lại các thông tin commit nên cần ánh xạ Subversion client thành “chủ nhân” Git. Server của SVN có thể dùng VisualSVN server để cài đặt mô phỏng trên Windows. Bước 1: Cài đặt VisualSVN server để tương tác với các clients
78 Hình 56- Giao diện VisualSVN Server Bước 2: Client SVN dùng Totoise SVN để tích hợp Git vào sử dụng Hình 57- Giao diện TortoiseSVN Bước 3: Tiến hành chuyển đổi SVN sang Git. Từ SVN Server tiến hành xuất repository về máy tính và lưu trữ trong thư mục của Git đang làm việc Hình trên đang có 2 file .txt trong repo có tên test cần chuyển đổi. Bước 4: Tiếp theo nhấn chuột phải Repo tên test -> all task -> export repo
79 Bước 5: Tùy vào các lựa chọn phù hợp nhu cầu, người dùng nhấn next Phía trên là chọn thư mục muốn lưu sau khi xuất repo của SVN và phía dưới là tên repo khi xuất. Cuối cùng Repo được xuất thành công.
80 Bước 6: Tiến hành vào thư mục đã trỏ tới khi xuất Repo SVN để xem kết quả Bước 7: Hình trên đã thấy Repo SVN xuất thành công. Tiếp đến tiến hành đưa Repo SVN đã xuất lên Github quản lý. Đầu tiên kéo thư mục từ kho Github xuống để đồng bộ với thư mục Local
81 Bước 8: Sử dụng câu lệnh đẩy lên Repo Master như thông thường đối với Git Bước 9: Lúc này ta truy cập trình duyệt vào trang Github theo kho quản lý code của nhóm, kiểm tra lại file đã được đưa lên thành công.
82 Thư mục SVN đã xuất hiện trên Repo tại Github. Việc chuyển đổi kho code từ SVN Server sang Git và đưa lên kho quản lý Github thành công.
83 CHƯƠNG 4: KẾT LUẬN Trong thời đại phát triển vượt bậc hiện nay, nhu cầu về thông tin ngày càng tăng trong mọi hoạt động nói chung và trao đổi thông tin nói riêng, thì nhu cầu trao đổi thông tin rất cần thiết để đẩy mạnh việc tạo ra những sản phẩm ngày càng có giá trị. Tin học hóa trong quản lý, quá trình áp dụng các thành tựu khoa học công nghệ thông tin vào các hoạt động quản lý. Quá trình này nhằm mục đích nhằm cắt giảm bớt thời gian, giải quyết công việc với tốc độc cao và độ chính xác cao. Việc áp dụng Git vào việc quản lý kho dữ liệu cho một dự án nào đó vô cùng quan trọng và cần thiết cả với những dự án lớn nhỏ nhất, với những dự án có nhiều thành viên tham gia xây dựng. Bài báo cáo này mang đến người đọc thấy rõ lợi ích mang lại từ Git. Nhờ có Git giúp đơn giản hóa công việc quản lý “công sức” đóng góp từ thành viên tham gia dự án. Git góp phần làm giảm sự đụng độ, hay sự bất cẩn một thành viên trong dự án vô tình làm hỏng cả một phần mềm gây ảnh hưởng tới khách hàng và công ty, điều này là thiệt hại lớn đối với doanh nghiệp điều mà không ai mong muốn. Đánh giá đề tài Những công việc đã làm được - Đánh giá tổng quan, tìm hiểu Git/Github - Cài đặt môi trường và triển khai Git Bash - Thao tác cấu hình các lệnh cơ bản (clone, init, push, …) - Thao tác cấu hình một số lệnh nâng cao (merge, branch, conflict, …) - So sánh Git với SVN - Triển khai chuyển đổi từ kho dữ liệu từ SVN sang Git Những công việc chưa làm được - Triển khai việc trộn kho code để thực hiện quản lý trên website - Nêu ra tính năng Workflow của Git - Triển khai LFS chưa có đủ dữ liệu lớn để thao tác kiểm thử. Hướng phát triển của đề tài
84 Git Flow là tên gọi của 1 công cụ (Command) hỗ trợ Branch Model do Vincent Driessen đề xuất ra, trong git-flow có 5 kiểu với mỗi vai trò khác nhau (tùy trường hợp là 6 kiểu) như Master Branch, Develop Branch, Release Branch, Hotfix Branch, Support Branch. Chuyển đổi các kiểu với nhau để phát triển bằng việc thiết lập trước các nhánh, những tập luật khi merge, dù có bao nhiêu lập trình viên cùng thời điểm phát triển vẫn có thể quản lý Branch dễ dàng, và tránh được những vấn đề do gộp nhánh. Git Flow đưa ra các quy ước để triển khai công việc. Nó được tổng kết qua quá trình làm việc thực tiễn của nhiều nhóm trên thế giới hiện nay và mang lại kết quả khả quan đáng kinh ngạc. Mục đích là các nhóm công việc triển khai song song nhưng không ảnh hưởng tới nhau. Các môi trường phát triển, Staging và Production tách biệt giúp quá trình kiểm thử (QA), trả lời phản hồi và xử lý các vấn đề được gọn gàng và thống nhất hơn. Ý tưởng là duy trì các nhánh Branch không đổi - không xoá (tính cố định) trong suốt dòng đời sản phẩm. Branch Master sẽ luôn là Branch chính áp dụng cho Production, trong khi các Branch Hotfix, Features hay Develop cung cấp các phiên bản để phục vụ QA và hoàn thiện trước khi được đẩy lên Master. Khác với cách thông thường tạo ra nhiều vấn đề xảy ra ngay trên Production, thứ mà chúng ta hay gọi là “rút kinh nghiệm từ những sai lầm thực tiễn”, Git Flow đẩy quá trình QA vào một phần bắt buộc cho cả lập trình viên, nhóm QA và yêu cầu sự hoàn thiện cao hơn về chất lượng đầu ra.
85 TÀI LIỆU THAM KHẢO Tài liệu [1] Zack Rusin, Git cheat sheet, Based on the work of: Sebastien Pierre Xprima Corp, 2007 [2] Scott Chacon, Ben Straub, Pro Git 2nd Edition, Apress, 2014 Website [3] https://backlog.com/git-tutorial/vn/reference/ [4] https://git-scm.com/doc [5] https://thachpham.com/series/git-co-ban [6] https://linuxacademy.com/blog/linux/git-terms-explained/ [7] https://laptrinhx.com/top-10-version-control-systems-87231571/ [8] https://xuanthulab.net/git-va-github/ [9] https://www.atlassian.com/git [10] https://www.linuxcloudvps.com/blog/how-to-install-svn-server-on-debian-9/ [11] https://kenhgiaiphap.com/news/github-la-gi-cach-su-dung-github-chi-tiet- 2ubc9q9 [12] https://lptech.asia/kien-thuc/git-la-gi-su-dung-git-nang-cao-chuan-git-flow

More Related Content

PPTX
Giới thiệu Git và một số tính năng cơ bản
Huy Nguyen Quang
 
DOC
Luận Văn Công Nghệ Thông Tin Tìm Hiểu Về Flutter Và Ứng Dụng.doc
sividocz
 
DOCX
Báo cáo môn đảm bảo chất lượng phần mềm
Thuyet Nguyen
 
PDF
Kiến trúc máy tính và hợp ngữ bài 05
Nhóc Nhóc
 
DOCX
Tìm hiểu về kỹ thuật Kiểm thử phần mềm
Nguyễn Anh
 
DOC
Báo Cáo Chuyên Đề Học Phần Kiểm Thử Mobile App Bán Quần Áo.doc
DV Viết Luận văn luanvanmaster.com ZALO 0973287149
 
DOCX
Tìm hiểu các kỹ thuật kiểm thử phần mềm ứng dụng trong lập trình Java.
Nguyễn Anh
 
PDF
Đề thi Kỹ thuật lập trình có lời giải
nataliej4
 
Giới thiệu Git và một số tính năng cơ bản
Huy Nguyen Quang
 
Luận Văn Công Nghệ Thông Tin Tìm Hiểu Về Flutter Và Ứng Dụng.doc
sividocz
 
Báo cáo môn đảm bảo chất lượng phần mềm
Thuyet Nguyen
 
Kiến trúc máy tính và hợp ngữ bài 05
Nhóc Nhóc
 
Tìm hiểu về kỹ thuật Kiểm thử phần mềm
Nguyễn Anh
 
Báo Cáo Chuyên Đề Học Phần Kiểm Thử Mobile App Bán Quần Áo.doc
DV Viết Luận văn luanvanmaster.com ZALO 0973287149
 
Tìm hiểu các kỹ thuật kiểm thử phần mềm ứng dụng trong lập trình Java.
Nguyễn Anh
 
Đề thi Kỹ thuật lập trình có lời giải
nataliej4
 

What's hot (20)

DOCX
Chương trình Quản lý Nhà Sách
BIC
 
DOCX
Đồ án kiểm thử phần mềm
Nguyễn Anh
 
DOCX
Khóa luận tốt nghiệp Phân tích thiết kế hệ thống thông tin quản lý ký túc xá ...
Duc Dinh
 
PDF
Báo Cáo Cuối Ký Thực Tập Tốt Nghiệp Xậy Dựng Web Bán Hàng Trực Tuyến bằng Ope...
hoainhan1501
 
PDF
Phân tích và thiết kế hệ thống quản lý quán Internet
nataliej4
 
PDF
XÂY DỰNG GAME CỜ VUA CHƠI QUA MẠNG
nataliej4
 
PDF
Giáo trình phân tích thiết kế hệ thống thông tin
Võ Phúc
 
PDF
Đảm bảo chất lượng phầm mềm (nguồn PTIT)
Thuyet Nguyen
 
PDF
Báo cáo đồ án tốt nghiệp "Ứng dụng trí tuệ nhân tạo nhận dạng chữ viết tay xâ...
The Boss
 
PDF
Đề tài: Xây dựng Website quản lý điểm trường Phổ thông, 9đ
Dịch vụ viết bài trọn gói ZALO: 0909232620
 
DOC
Bao cao da lap trinh manh
Bồ Công Anh
 
PPTX
Slide báo cáo đồ án tốt nghiệp "Website cửa hàng điện thoại trực tuyến"
Tú Cao
 
PDF
Thiết kế csdl quản lý nhân sự
leemindinh
 
DOC
Hệ thống quản lý rạp chiếu phim
vennguyennoinho
 
DOCX
Báo cáo đồ án môn công nghệ phần mềm
RiTa15
 
DOCX
Giới thiệu về Rational Rose và Các diagram
Huy Vũ
 
PDF
BÁO CÁO ĐỒ ÁN MÔN HỌC ĐIỆN TOÁN ĐÁM MÂY ĐỀ TÀI: TÌM HIỂU VÀ SỬ DỤNG AMAZON WE...
nataliej4
 
DOC
đồ áN chuyên đề đồ họa ứng dụng
Làm Thuê Đồ Án
 
PDF
lý thuyết cơ sở dữ liệu phân tán
Ngo Trung
 
DOCX
Xây dựng cơ sở dữ liệu trong quản lý nhân sự
AskSock Ngô Quang Đạo
 
Chương trình Quản lý Nhà Sách
BIC
 
Đồ án kiểm thử phần mềm
Nguyễn Anh
 
Khóa luận tốt nghiệp Phân tích thiết kế hệ thống thông tin quản lý ký túc xá ...
Duc Dinh
 
Báo Cáo Cuối Ký Thực Tập Tốt Nghiệp Xậy Dựng Web Bán Hàng Trực Tuyến bằng Ope...
hoainhan1501
 
Phân tích và thiết kế hệ thống quản lý quán Internet
nataliej4
 
XÂY DỰNG GAME CỜ VUA CHƠI QUA MẠNG
nataliej4
 
Giáo trình phân tích thiết kế hệ thống thông tin
Võ Phúc
 
Đảm bảo chất lượng phầm mềm (nguồn PTIT)
Thuyet Nguyen
 
Báo cáo đồ án tốt nghiệp "Ứng dụng trí tuệ nhân tạo nhận dạng chữ viết tay xâ...
The Boss
 
Đề tài: Xây dựng Website quản lý điểm trường Phổ thông, 9đ
Dịch vụ viết bài trọn gói ZALO: 0909232620
 
Bao cao da lap trinh manh
Bồ Công Anh
 
Slide báo cáo đồ án tốt nghiệp "Website cửa hàng điện thoại trực tuyến"
Tú Cao
 
Thiết kế csdl quản lý nhân sự
leemindinh
 
Hệ thống quản lý rạp chiếu phim
vennguyennoinho
 
Báo cáo đồ án môn công nghệ phần mềm
RiTa15
 
Giới thiệu về Rational Rose và Các diagram
Huy Vũ
 
BÁO CÁO ĐỒ ÁN MÔN HỌC ĐIỆN TOÁN ĐÁM MÂY ĐỀ TÀI: TÌM HIỂU VÀ SỬ DỤNG AMAZON WE...
nataliej4
 
đồ áN chuyên đề đồ họa ứng dụng
Làm Thuê Đồ Án
 
lý thuyết cơ sở dữ liệu phân tán
Ngo Trung
 
Xây dựng cơ sở dữ liệu trong quản lý nhân sự
AskSock Ngô Quang Đạo
 
Ad

Similar to [Đồ án môn học] - Đề tài: Tìm hiểu Git và Github (20)

DOC
luan van thac si tim hieu he thong nguon mo ho tro hoc truc tuyen
Dịch vụ viết thuê Luận Văn - ZALO 0932091562
 
DOCX
Nghiên cứu cơ chế routing của Cisco, mô phỏng trên nền GNS3
phamvotuanthanh
 
PDF
Đề tài: Chỉnh sửa giao diện cho website sử dụng hệ quản trị nội dung
Dịch vụ viết bài trọn gói ZALO: 0909232620
 
DOC
Bao cao thuc tap
Leo Aurico
 
PDF
Khóa luận tốt nghiệp Thiết kế và quản trị hệ thống mạng cho một trường cao đẳ...
NuioKila
 
PDF
ThucTapDoanhNghiep_TinHocDaiDuong_NguyenChiThanh
PhamNhatKhoi
 
DOCX
Báo cáo cuối kỳ athena
Ringpig Luancio
 
PDF
Ứng dụng AR trên ARtoolkit + Nodejs
Ivan Nguyen
 
DOCX
Báo Cáo Thực Tập Cuối Kỳ Athena - Nguyễn Minh Chương
masternokizep
 
DOCX
Báo cáo thực tập cuối kỳ Nguyễn Minh Chương
masternokizep
 
DOCX
Bao cao cuoi ki_ Nguyen Dang Van
Nguyễn Vân
 
PDF
Nghiên cứu và triển khai hệ thống Private Cloud cho các ứng dụng đào tạo và ...
hieu anh
 
PDF
Luận văn: Nghiên cứu và triển khai hệ thống Private Cloud cho các ứng dụng đà...
Viết thuê trọn gói ZALO 0934573149
 
DOC
Luận văn Thạc sĩ Xây dựng website bán hàng sử dụng phần mềm mã nguồn mở NOPCO...
Dịch vụ viết thuê Luận Văn - ZALO 0932091562
 
DOCX
Báo cáo cuối kì (nguyễn phượng nhung)
Nhung Nguyễn
 
PDF
Nghiên cứu mô hình điện toán đám mây, cài đặt thử nghiệm và đánh giá.pdf
Man_Ebook
 
DOCX
Baocaocuoiki
ngotrieuhuan
 
DOCX
Báo cáo cuối kỳ
Khỉ Lùn
 
DOC
Bao cao + bia
Nguyễn Văn Khoa
 
PDF
Đề tài: Xây dựng ứng dụng hỗ trợ giao tiếp trực tuyến hội nghị
Dịch vụ viết bài trọn gói ZALO 0917193864
 
luan van thac si tim hieu he thong nguon mo ho tro hoc truc tuyen
Dịch vụ viết thuê Luận Văn - ZALO 0932091562
 
Nghiên cứu cơ chế routing của Cisco, mô phỏng trên nền GNS3
phamvotuanthanh
 
Đề tài: Chỉnh sửa giao diện cho website sử dụng hệ quản trị nội dung
Dịch vụ viết bài trọn gói ZALO: 0909232620
 
Bao cao thuc tap
Leo Aurico
 
Khóa luận tốt nghiệp Thiết kế và quản trị hệ thống mạng cho một trường cao đẳ...
NuioKila
 
ThucTapDoanhNghiep_TinHocDaiDuong_NguyenChiThanh
PhamNhatKhoi
 
Báo cáo cuối kỳ athena
Ringpig Luancio
 
Ứng dụng AR trên ARtoolkit + Nodejs
Ivan Nguyen
 
Báo Cáo Thực Tập Cuối Kỳ Athena - Nguyễn Minh Chương
masternokizep
 
Báo cáo thực tập cuối kỳ Nguyễn Minh Chương
masternokizep
 
Bao cao cuoi ki_ Nguyen Dang Van
Nguyễn Vân
 
Nghiên cứu và triển khai hệ thống Private Cloud cho các ứng dụng đào tạo và ...
hieu anh
 
Luận văn: Nghiên cứu và triển khai hệ thống Private Cloud cho các ứng dụng đà...
Viết thuê trọn gói ZALO 0934573149
 
Luận văn Thạc sĩ Xây dựng website bán hàng sử dụng phần mềm mã nguồn mở NOPCO...
Dịch vụ viết thuê Luận Văn - ZALO 0932091562
 
Báo cáo cuối kì (nguyễn phượng nhung)
Nhung Nguyễn
 
Nghiên cứu mô hình điện toán đám mây, cài đặt thử nghiệm và đánh giá.pdf
Man_Ebook
 
Baocaocuoiki
ngotrieuhuan
 
Báo cáo cuối kỳ
Khỉ Lùn
 
Bao cao + bia
Nguyễn Văn Khoa
 
Đề tài: Xây dựng ứng dụng hỗ trợ giao tiếp trực tuyến hội nghị
Dịch vụ viết bài trọn gói ZALO 0917193864
 
Ad

Recently uploaded (6)

PDF
Bài giảng - Phat Trien UD Tren Linux_Final_14092023.pdf
nhhon8
 
DOCX
Đệ Quy (Recursion) trong Java | Giải thích và Ứng dụng
Java Highlight
 
PPTX
bài thuyết trình thi công cầu elearning 3.pptx
KimUyn17
 
PPTX
thi công cầu thuyết trình elearning 2.pptx
KimUyn17
 
DOCX
Đánh giá độ tin cậy lưới điện Khu II Trường Đại học Cần Thơ
lamluanvan.net Viết thuê luận văn
 
DOCX
GIẢI PHÁP BẢO MẬT THÔNG TIN LOGISTICS CHO DOANH NGHIỆP VIETTEL POST TRONG KỶ ...
lamluanvan.net Viết thuê luận văn
 
Bài giảng - Phat Trien UD Tren Linux_Final_14092023.pdf
nhhon8
 
Đệ Quy (Recursion) trong Java | Giải thích và Ứng dụng
Java Highlight
 
bài thuyết trình thi công cầu elearning 3.pptx
KimUyn17
 
thi công cầu thuyết trình elearning 2.pptx
KimUyn17
 
Đánh giá độ tin cậy lưới điện Khu II Trường Đại học Cần Thơ
lamluanvan.net Viết thuê luận văn
 
GIẢI PHÁP BẢO MẬT THÔNG TIN LOGISTICS CHO DOANH NGHIỆP VIETTEL POST TRONG KỶ ...
lamluanvan.net Viết thuê luận văn
 

[Đồ án môn học] - Đề tài: Tìm hiểu Git và Github

  • 1. BỘ CÔNG THƯƠNG TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP THỰC PHẨM TP. HCM KHOA CÔNG NGHỆ THÔNG TIN ĐỒ ÁN MÔN HỌC Đề tài: TÌM HIỂU GIT VÀ GITHUB Giảng viên hướng dẫn: ThS. Trần Thị Bích Vân Sinh viên thực hiện: Mai Thành Tâm 2033172075 Vũ Quang Huy 2033172018 TP. HCM, Tháng 7 Năm 2020
  • 2. NHẬN XÉT CỦA GIẢNG VIÊN HƯỚNG DẪN ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... Nhóm em chân thành cảm ơn! TPHCM, ngày…tháng…năm 202.. GIẢNG VIÊN
  • 3. NHẬN XÉT CỦA GIẢNG VIÊN PHẢN BIỆN ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... ....................................................................................................................................... Nhóm em chân thành cảm ơn! TPHCM, ngày…tháng…năm 202.. GIẢNG VIÊN
  • 4. LỜI CẢM ƠN Trong thời gian làm đồ án một chỉ, nhóm em đã nhận được nhiều sự giúp đỡ, đóng góp ý kiến và chỉ bảo nhiệt tình của Thầy/Cô. Đầu tiên, nhóm em xin trân trọng gửi lời cảm ơn chân thành đến Th.S Trần Thị Bích Vân, cô đang là giảng viên hiện đang công tác tại trường Đại Học Công Nghiệp Thực Phẩm TPHCM, người đã tận tình hướng dẫn, chỉ bảo nhóm em trong suốt quá trình làm đồ án. Cô đã dùng tất cả kinh nghiệm quý báu của mình trong suốt những năm giảng dạy để giúp nhóm em không chỉ hoàn thành tốt hơn đồ án của nhóm, bên cạnh đó còn chỉ dạy nhóm em cách xử lý những tình huống mà các anh chị khóa trước trong quá trình báo cáo đồ án, khóa luận đã gặp phải. Nhờ chỉ dạy và khuyên răn của cô đã giúp nhóm em tự tin hơn trước khi báo cáo đồ án của mình. Em cũng xin chân thành cảm ơn các Thầy/Cô trong trường Đại Học Công Nghiệp Thực Phẩm TP. HCM, cũng như các Thầy/Cô trong khoa Công Nghệ Thông Tin đã dạy dỗ cho em những kiến thức từ những môn đại cương đến các môn chuyên ngành, giúp nhóm em có được cơ sở lý thuyết vững vàng và tạo điều kiện giúp đỡ em trong suốt quá trình học tập. Nhờ những đóng góp chân thành, thẳng thắn của Thầy/Cô, bạn bè đã làm nguồn cảm hứng, động lực góp phần giúp nhóm em có những ý tưởng bổ sung kịp thời nhằm đạt được kết quả tốt nhất cho đề tài đồ án này. Một lần nữa, nhóm em xin dành lời chúc quý giá nhất tới những quý ân nhân. Kính chúc Khoa Công Nghệ Thông Tin cũng như các quý Thầy/Cô lời chúc sức khỏe và ngày càng thành công trong sự nghiệp “người lái đò”. Do đây là một bài báo cáo đầu tiên của nhóm em nên vẫn còn nhiều thiếu sót, tầm nhìn hạn hẹp, trình bày còn sơ sài nên mong nhận được sự thông cảm của thầy cô cùng những nhận xét khách quan cho nhóm em lấy điều đó làm kinh nghiệm triển khai trong các bài báo cáo sau này.
  • 5. MỤC LỤC CHƯƠNG 1: GIỚI THIỆU......................................................................................1 1.1 Source Code ..............................................................................................1 1.1.1 Khái niệm cơ bản.................................................................................1 1.1.2 Quản lý Source Code...........................................................................1 1.2 Các mô hình quản lý ................................................................................2 1.2.1 Mô hình quản lý tập trung ...................................................................3 1.2.2 Mô hình quản lý phân tán....................................................................5 1.2.3 Sự phổ biến của hai mô hình...............................................................6 1.3 Github (https://github.com) ....................................................................6 1.3.1 Sơ lược về Github................................................................................6 1.3.2 Lịch sử và sự kiện của Github.............................................................7 1.3.2.1 Lịch sử ...........................................................................................7 1.3.2.2 Sự kiện ...........................................................................................8 1.3.3 Phân loại Github..................................................................................9 1.3.4 Tính năng API của Github.................................................................10 1.3.5 Nền tảng làm việc của Github ...........................................................11 1.3.5.1 Thao tác với Repo ở Local ..........................................................11 1.3.5.2 Thao tác với Repo ở Server .........................................................12 1.4 Git ............................................................................................................12 1.4.1 Sơ lược về Git....................................................................................12 1.4.2 Lịch sử Git.........................................................................................12 1.4.3 Đặc điểm của Git...............................................................................13 1.4.3.1 Tương tác dữ liệu với Git ............................................................13 1.4.3.2 Cơ chế Snapshot của Git .............................................................14 1.4.3.3 Thao tác Local của Git................................................................14 1.4.3.4 Định dạng đối tượng trong Git....................................................15 1.4.3.5 Tính toàn vẹn của Git ..................................................................17 1.4.3.6 Tính dễ dàng trong Git ................................................................18
  • 6. 1.4.4 Ưu và nhược điểm của Git ................................................................18 1.4.4.1 Ưu điểm .......................................................................................19 1.4.4.2 Nhược điểm..................................................................................19 1.5 Các khái niệm trong Git và Github......................................................20 1.6 Git Remote Server..................................................................................23 1.6.1 Giao thức Local .................................................................................24 1.6.2 Giao thức HTTP ................................................................................25 1.6.2.1 Smart HTTP.................................................................................25 1.6.2.2 Dump HTTP.................................................................................25 1.6.3 Giao thức SSH...................................................................................26 1.6.4 Git daemon ........................................................................................27 1.7 Bài toán dung lượng trong Git..............................................................27 1.7.1 Git đóng gói.......................................................................................28 1.7.2 Git LFS..............................................................................................30 CHƯƠNG 2: CÀI ĐẶT GIT..................................................................................32 2.1 Các môi trường Git hỗ trợ.....................................................................32 2.1.1 Trên Linux.........................................................................................32 2.1.2 Trên Windows ...................................................................................33 2.1.3 Phiên bản GUI...................................................................................37 CHƯƠNG 3: TRIỂN KHAI...................................................................................38 3.1 Cấu hình Github.....................................................................................38 3.1.1 Tạo Github Repository ......................................................................38 3.1.2 Tạo Github Branch ............................................................................41 3.1.3 Sử dụng Github..................................................................................42 3.1.3.1 Lệnh Commit trên Github............................................................42 3.1.3.2 Lệnh Pull trên Github..................................................................43 3.1.3.3 Lệnh Merge trên Github..............................................................44 3.1.4 Xóa Github Repository......................................................................45 3.2 Cấu hình Git cơ bản...............................................................................46
  • 7. 3.2.1 Thiết lập ban đầu ...............................................................................46 3.2.1.1 Định danh ....................................................................................47 3.2.1.2 Kiểm tra cài đặt...........................................................................47 3.2.1.3 Trợ giúp.......................................................................................48 3.2.2 Các lệnh cơ bản .................................................................................49 3.2.2.1 Khởi tạo Git Repository ban đầu.................................................49 3.2.2.2 Cách Clone dự án bằng Git.........................................................52 3.3 Kết nối Git đến Github qua SSH ..........................................................54 3.3.1 Khái niệm SSH..................................................................................54 3.3.2 Cơ chế làm việc SSH.........................................................................54 3.3.3 Các bước tạo khóa và kết nối Github................................................54 3.4 Cấu hình Git nâng cao ...........................................................................58 3.4.1 Nhánh là gì, tại sao phải phân nhánh ................................................58 3.4.2 Tạo nhánh..........................................................................................59 3.4.3 Phân nhánh ........................................................................................59 3.4.4 Gộp nhánh .........................................................................................60 3.4.5 Xóa nhánh..........................................................................................61 3.5 Giải quyết xung đột trên Git .................................................................62 3.5.1 Xung đột tập tin trong một nhánh .....................................................62 3.5.2 Xung đột tập tin trong nhiều nhánh...................................................65 3.6 Cài đặt, cấu hình Git LFS......................................................................70 3.6.1 Cài đặt Git LFS..................................................................................70 3.6.2 Cấu hình Git LFS ..............................................................................71 3.7 Tích hợp với hệ thống SVN ...................................................................76 3.7.1 Giới thiệu SVN2Git...........................................................................76 3.7.2 Cấu hình Git – SVN ..........................................................................77 CHƯƠNG 4: KẾT LUẬN ......................................................................................83 TÀI LIỆU THAM KHẢO ......................................................................................85
  • 8. DANH MỤC KÝ HIỆU, CHỮ VIẾT TẮT Viết tắt Tiếng Anh Tiếng Việt GUI Graphical User Interface Giao diện đồ họa người dùng SSH Secure Shell Giao thức điều khiển từ xa bảo mật VCS Version Control System Phần mềm quản lý phiên bản dự án LFS Large File Storage Lưu trữ tập tin dung lượng lớn HTTP HyperText Transfer Protocol Giao thức truyền tải siêu văn bản HTTPS HyperText Transfer Protocol Secure Giao thức siêu văn bản bảo mật API Application Programming Interface Giao diện lập trình ứng dụng SVN Subversion Hệ thống quản lý tập trung QA Quality Assurance Đảm bảo chất lượng CVCS Centralized Version Control System Hệ thống kiếm soát tập trung DVCS Distributed Version Control System Hệ thống kiểm soát phân tán
  • 9. MỤC LỤC HÌNH ẢNH Hình 1- Mô hình Local VCS------------------------------------------------------------------2 Hình 2- Hai mô hình Version Control ------------------------------------------------------3 Hình 3- Mô hình CVCS -----------------------------------------------------------------------4 Hình 4- Rủi ro tồn động tập trung một chỗ ------------------------------------------------4 Hình 5- Mô hình DVCS -----------------------------------------------------------------------5 Hình 6- Xu hướng phát triển hai mô hình quản lý phiên bản----------------------------6 Hình 7- Trang chủ Github--------------------------------------------------------------------7 Hình 8- Dự án Arctic Code Vault -----------------------------------------------------------8 Hình 9- Tương tác dữ liệu với các VCS -------------------------------------------------- 13 Hình 10- Tương tác dữ liệu với Git ------------------------------------------------------- 14 Hình 11- Mô tả cơ chế Snapshot ---------------------------------------------------------- 14 Hình 12- Hàm băm trong Git -------------------------------------------------------------- 17 Hình 13- Website Trustradius đánh giá Git---------------------------------------------- 18 Hình 14- Local Repo và Remote Repo---------------------------------------------------- 20 Hình 15- Minh họa hành động Merge ---------------------------------------------------- 21 Hình 16- Minh họa hành động Commit--------------------------------------------------- 22 Hình 17- Minh họa các hoạt động của Staging------------------------------------------ 22 Hình 18- Công dụng Git Remote Server-------------------------------------------------- 23 Hình 19- Đường dẫn URL của Local Repo ---------------------------------------------- 24 Hình 20- Nhiều Commit tăng dung lượng Repo----------------------------------------- 28 Hình 21- Mô tả lệnh git gc ----------------------------------------------------------------- 28 Hình 22- Công cụ Git LFS------------------------------------------------------------------ 30 Hình 23- Website tải Git chính thức của nhà phát hành ------------------------------- 32 Hình 24- Lựa chọn Sublime Text làm Git Editor---------------------------------------- 34 Hình 25- Hai chương trình khởi chạy ứng với hai môi trường------------------------ 37 Hình 26- Công cụ bên thứ 3 hỗ trợ GUI cho Git---------------------------------------- 37 Hình 27- Nơi đăng ký tài khoản Github -------------------------------------------------- 38 Hình 28- Khởi tạo Github Repositories--------------------------------------------------- 39
  • 10. Hình 29- Đặt tên cho Repo ----------------------------------------------------------------- 39 Hình 30- Mô tả Repo dự án ---------------------------------------------------------------- 39 Hình 31- Hai chế độ phân quyền của Repo Github ------------------------------------- 39 Hình 32- Template tùy chọn Repo Github------------------------------------------------ 40 Hình 33- Đặt tên nhánh trên Github ------------------------------------------------------ 41 Hình 34- Repo hiện có 2 nhánh------------------------------------------------------------ 42 Hình 35- Tạo pull request trên Github---------------------------------------------------- 44 Hình 36- Repo trên Github đã xóa -------------------------------------------------------- 46 Hình 37- Xem thông số mặc định---------------------------------------------------------- 47 Hình 38- Xem xét tham số name thuộc User--------------------------------------------- 48 Hình 39- Website tập hợp các lệnh config ----------------------------------------------- 48 Hình 40- Các lệnh config Git -------------------------------------------------------------- 48 Hình 41- Xem trợ giúp lệnh commit------------------------------------------------------- 49 Hình 42- Tạo một thư mục chứa tập tin -------------------------------------------------- 49 Hình 43- Tạo file dự án --------------------------------------------------------------------- 50 Hình 44- Tải Github Repo bằng file zip -------------------------------------------------- 53 Hình 45- Lấy về toàn bộ dự án------------------------------------------------------------- 54 Hình 46- Thêm khóa bí mật vào SSH - agent -------------------------------------------- 55 Hình 47- Nội dung khóa công khai-------------------------------------------------------- 56 Hình 48- Quy trình chia nhánh ------------------------------------------------------------ 58 Hình 49- Rẽ nhánh tại Snapshot C2------------------------------------------------------- 66 Hình 50- Hai nội dung xung đột gộp nhánh --------------------------------------------- 68 Hình 51- Giữ lại nội dung của Master---------------------------------------------------- 68 Hình 52- Lịch sử Commit trên Alpha ----------------------------------------------------- 69 Hình 53- Lịch sử Commit trên Master ---------------------------------------------------- 69 Hình 54- Trang chủ tải Git LFS cho Windows ------------------------------------------ 70 Hình 55- Mô hình sử dụng Subversion clients------------------------------------------- 77 Hình 56- Giao diện VisualSVN Server---------------------------------------------------- 78 Hình 57- Giao diện TortoiseSVN---------------------------------------------------------- 78
  • 11. LỜI NÓI ĐẦU Với tốc độ phát triển như vũ bão của ngành Công Nghệ Thông Tin, kéo theo sự đòi hỏi tỉ mỉ, chính xác và nhanh chóng trong việc tạo ra sản phẩm để đáp ứng nhu cầu xã hội. Một trong những vấn đề đang được quan tâm trong công nghệ là vấn đề về mã lệnh. Khi lập trình, có trường hợp lập trình viên sơ xuất xoá đi một đoạn mã lệnh quan trọng mà họ muốn lấy lại đoạn mã lệnh đó trong một chương trình dự án lớn có thể gây khó khăn cho họ. Ngoài ra việc nhớ lại chính xác những gì mình đã viết lại là một trở ngại khác. Việc sử dụng phần mềm quản lý phiên bản mã nguồn sẽ giúp mọi việc đơn giản hơn rất nhiều vì phần mềm cho phép người dùng quay lại phiên bản chỉnh sửa trước của tập tin dễ dàng. Việc lập trình giống như một ngành sản xuất, lập trình viên tạo ra sản phẩm phục vụ khách hàng, không ngừng cải tiến sản phẩm của mình sao cho phù hợp với nhu cầu thị trường, hỗ trợ tốt cho khách hàng. Để mọi việc dễ dàng hơn, bản thân lập trình viên thực sự cần đến một công cụ để quản lý sản phẩm của mình. Như các sản phẩm hàng hoá khác người dùng có thể dùng các phần mềm quản lý kho, quản lý dây chuyền sản phẩm, v.v. Đối với phần mềm, chúng ta có các công cụ quản lý phiên bản mã nguồn lệnh có thể kể đến như Git, SVN, Subversion, Mercurial, ... Mỗi công cụ có những đặc điểm và ưu thế riêng, trong số các công cụ này, Git cùng Github là bộ đôi công cụ quản lý mã nguồn lệnh phổ biến nhất và cũng là chủ đề chính của bài báo cáo này, nội dung được cô đọng trong những ý sau: - Giúp người dùng có cái nhìn tổng quát về công cụ quản lý mã nguồn lệnh nói chung và Git nói riêng. - Hiểu được cơ bản cách Git hoạt động và nên áp dụng như thế nào cho dự án của mình. - Tìm hiểu cách cài đặt Git và sử dụng Github trên nền Web - Làm quen với một số câu lệnh cơ bản của Git - Tìm hiểu một số lệnh nâng cao trong Git - Demo một số lệnh - Chuyển đổi kho SVN sang Git - Trộn kho code Từ các nội dung trên, những công dụng hữu ích cùng sự tiện lợi đến không ngờ của Git/Github sẽ được nhóm em đưa ra trong bài báo cáo.
  • 12. 1 CHƯƠNG 1: GIỚI THIỆU 1.1 Source Code 1.1.1 Khái niệm cơ bản Source Code (mã nguồn) theo định nghĩa trong tin học là một dãy các tập lệnh được viết bởi lập trình viên sử dụng các ngôn ngữ lập trình. Mã nguồn được xem là thành phần cơ bản của chương trình máy tính. Các lập trình viên có thể đọc và hiểu rõ mục đích của nó. Dựa vào trình biên dịch, mã nguồn của chương trình chuyển đổi thành ngôn ngữ mà máy tính có thể hiểu, có thể thực hiện gọi là ngôn ngữ máy. Mã nguồn có thể là “mở” hoặc “độc quyền” dựa theo các thỏa thuận cấp phép của chủ sở hữu. Một ví dụ điển hình là bộ phần mềm Microsoft Office có mã nguồn độc quyền thuộc Microsoft chỉ cấp cho khách hàng quyền truy cập vào các tệp thực thi và tệp thư viện liên quan hoặc một ví dụ khác là bộ phần mềm Apache OpenOffice có mã nguồn mở có thể được tải xuống và chỉnh sửa. Mục đích của mã nguồn cung cấp nền tảng cho việc tạo phần mềm, cho người dùng vào tùy chỉnh dễ dàng các thiết lập nếu cần. Các nhà phát triển sử dụng mã nguồn tạo các chương trình tương tự có tùy chỉnh sử dụng cho các nền tảng vận hành khác nhau, có thể xem Android của Google là một ví dụ khi từ nó, một phiên bản ROM gốc làm phần vùng lưu trữ hệ điều hành cho điện thoại thông minh, có đặc điểm “mở” cho phép các hãng sản xuất điện thoại tùy biến thành phiên bản ROM OS dành riêng cho sản phẩm điện thoại của riêng họ. Ngoài ra, việc giúp truy cập mã nguồn dễ dàng giúp các lập trình viên đóng góp cho cộng đồng công nghệ, chia sẻ mã nguồn cho mục đích học tập, tái chế các thành phần của nó cho các ứng dụng khác. Các lập trình viên sử dụng trình soạn thảo văn bản, công cụ lập trình trực quan hoặc môi trường phát triển tích hợp (IDE) như bộ công cụ phát triển phần mềm (SDK) để tạo mã nguồn. Trong môi trường phát triển chương trình lớn, các hệ thống quản lý phiên bản (Version Control System) có công dụng hỗ trợ lập trình viên phân nhánh, theo dõi, giám sát trạng thái và cấp độ khác nhau của các tệp mã nguồn. 1.1.2 Quản lý Source Code Version Control System là hệ thống quản lý phiên bản mã nguồn, một phần mềm giúp các lập trình viên, đặc biệt trong lĩnh vực phần mềm làm việc được với nhau và duy trì đầy đủ công việc vì tính năng không cho phép ghi đè lên các thay đổi của nhau. Hệ thống được cả doanh nghiệp lớn, nhỏ sử dụng do lợi ích thuận lợi, tiết kiệm một khoản chi phí. Hệ thống này là công cụ ghi lại các thay đổi của một file,
  • 13. 2 cấu trúc chương trình, từ các tệp mã lệnh cho đến các tệp hình ảnh, video. Cơ chế hoạt động và lợi ích có thể hiểu như sau: - Tạo ra các phiên bản khác nhau của dự án, dễ dàng cho việc giám sát. - Có ích cho các ngành nghề như lập trình viên, người làm đồ họa hay thiết kế web. - Sử dụng công cụ quản lý khôn ngoan có thể giúp người dùng chuyển qua lại các trạng thái hoặc toàn bộ cả dự án nếu muốn, so sánh với các thay đổi theo thời gian, xem người nào là người cuối cùng chỉnh sửa gì đó, ai là người phải chịu trách nhiệm. Từ những điều trên cho thấy công cụ Version Control mang lại lợi ích, trợ giúp nhiều cho một dự án – nhất là dự án liên quan đến code, một team có thể tự chia tạo ra một phiên bản riêng (Branch) cho mình, làm việc độc lập trên đó và sau đó sẽ gộp (Merge) mã lệnh lại. Mọi thứ còn lại đều được Version Control đánh dấu thời gian rõ ràng, theo dõi, phân tích tiến độ dự án, giúp công việc tiện lợi hơn rất nhiều. 1.2 Các mô hình quản lý Giải pháp đơn giản nhất sử dụng trước đây khi người dùng chuyển thư mục họ cần sang một thư mục khác. Được xem là một thao tác khá đơn giản. Tuy nhiên, điểm yếu của giải pháp này là người dùng có thể quên đường dẫn và vô tình ghi hoặc sao chép nhầm tập tin mà mình không mong muốn. Hình 1- Mô hình Local VCS
  • 14. 3 Từ đó, các lập trình viên đã phát triển ra Local VCS có một cơ sở dữ liệu đơn giản để giữ tất cả sự thay đổi của file dưới hệ thống kiểm soát sửa đổi. Công cụ đại diện cho giải pháp này là RCS, được phân phối sử dụng với nhiều máy tính hiện nay. Hai mô hình phổ biến nhất của VCS là mô hình quản lý phiên bản phân tán (CVCS) và mô hình quản lý phiên bản tập trung (DVCS) Hình 2- Hai mô hình Version Control 1.2.1 Mô hình quản lý tập trung Centralized Version Control System (CVCS): hệ thống quản lý phiên bản tập trung sử dụng một server để chứa tất cả lịch sử hay phiên bản mã nguồn và số lượng client kết nối vào để lấy file rất nhiều, tập trung tại một nơi. Để làm việc với dự án, trước hết, người dùng hoặc khách hàng cần lấy mã từ kho lưu trữ chính hoặc máy chủ. Máy khách cần liên lạc với máy chủ để kéo tất cả các mã nguồn hay phiên bản hiện tại từ máy chủ sang máy cục bộ của họ. Nói cách khác, người dùng cần lấy một bản cập nhật từ kho lưu trữ chính và sau đó nhận một bản sao mã nguồn cục bộ trong hệ thống của mình. Khi nhận được phiên bản mã nguồn mới nhất, máy khách thực hiện các thay đổi của riêng mình trong mã nguồn, sau đó hợp nhất mã nguồn của riêng họ vào kho lưu trữ chính hoặc tạo một phiên bản mới từ mã nguồn đó. Ưu điểm: - Giải quyết vấn đề các lập trình viên muốn làm việc với nhau trên các hệ thống khác nhau
  • 15. 4 - Có lợi ích với local VCSs, mọi người đều biết tiến độ công việc của thành viên khác trong dự án - Người quản trị có toàn quyền quyết định công việc của mỗi thành viên trong nhóm - Dễ dàng quản trị, kiểm soát, phân quyền dẫn tới cơ chế bảo mật Nhược điểm: - Nếu server bị sập trong một khoảng thời gian nào đó thì không một ai có thể làm việc hay lưu file trong khoảng thời gian đó - Nếu ổ đĩa cứng chứa cơ sở dữ liệu bị gián đoạn, hay là chưa có bản backup, toàn bộ lịch sử phiên bản của dự án sẽ bị mất hết Hình 3- Mô hình CVCS Sở hữu toàn bộ phiên bản dự án tập trung vào một nơi thì rủi ro xảy ra rất cao, đây là khi xuất hiện mô hình DVCS. Những công cụ tiêu biểu dành cho mô hình quản lý tập trung là SVN, CVS, Perforce … Hình 4- Rủi ro tồn động tập trung một chỗ
  • 16. 5 1.2.2 Mô hình quản lý phân tán Distributed Version Control System (DVCS): Hệ thống quản lý phiên bản phân tán ra đời để khắc phục nhược điểm của CVCS, được xem là một xu hướng hiện nay của hệ thống quản lý phiên bản. Hệ thống hoạt động theo mô hình ngang hàng, cơ sở mã nguồn được phân phối giữa các máy tính của máy khách, nhà phát triển riêng lẻ. Bản sao của cơ sở mã nguồn được lưu trên máy khách. Các nhà phát triển thực hiện chỉnh sửa trong bản sao cục bộ cùa họ. Khi họ muốn tích hợp vào bản sao chính, họ phải đưa yêu cầu cho chủ sở hữu bản sao chính đồng ý hợp nhất các thay đổi đó vào bản sao chính. Nhóm em xin trình bày những cơ chế cũng như ưu điểm của hệ thống quản lý phân tán qua các ý sau: - Giống với CVCS có một máy chủ chứa cơ sở dữ liệu lưu trữ các phiên bản của file - Các máy khách kết nối vào server không chỉ lấy file mà còn lấy luôn cả hệ thống cơ sở dữ liệu - Khi server bị sập, các máy khách vẫn làm việc được bình thường, thao tác trên cơ sở dữ liệu lưu ở máy trạm, sau đó có thể commit (chuyển) lên server nếu được phục hồi - Nếu cơ sở dữ liệu ở server, máy khách cũng có thể được xem là giải pháp Backup để phục hồi cho server Hình 5- Mô hình DVCS Ngoài ra, rất nhiều hệ thống phân tán còn hoạt động tốt với một vài hệ thống Remote Repositories, người dùng có thể tương tác với nhiều nhóm người dùng khác
  • 17. 6 nhau trong nhiều cách chỉ với trong một dự án. Điều này cho phép bạn thiết lập một số loại quy trình công việc mà trở nên bất khả thi trong CVCS – đó chính là một số loại mô hình phân tán. Các công cụ tiêu biểu của loại mô hình hệ thống này là Git, Mercurial, Bazaar…. 1.2.3 Sự phổ biến của hai mô hình Hình 6- Xu hướng phát triển hai mô hình quản lý phiên bản Google đã đưa ra một bảng xu hướng cho thấy mức độ phổ biến của hai mô hình hệ thống hiện đang được sử dụng trên toàn thế giới. Dựa vào kết quả, ta thấy được DVCS có nhiều ưu điểm hơn và phổ biến hơn CVCS. Về việc chọn lựa sử dụng hệ thống nào còn tùy thuộc vào đối tượng người dùng hoặc một người mới bắt đầu làm quen với hệ thống mang lại cho họ sự thuận tiện. Tuy nhiên, bản chất DVCS vẫn mang lại nhiều lợi ích hơn cùng những câu lệnh vận hành của nó. 1.3 Github (https://github.com) Ở nội dung này, nhóm em sẽ trình bày về hệ thống quản lý mã nguồn Github, đồng thời đóng vai trò là Server của Git. Github rất phổ biến, luôn là gợi ý đầu tiên cho người dùng có nhu cầu quản lý mã nguồn lệnh của mình trước khi họ biết đến Git. 1.3.1 Sơ lược về Github Github, một hệ thống quản lý dự án lớn nhất dành cho Git Repository, là nguồn lưu dữ liệu mở lớn nhất hiện nay. Nó được xem là một dịch vụ Server trung tâm công cộng giúp quản lý nhiều phiên bản Code, lưu trữ chúng và là một mạng xã hội giúp cho lập trình viên tương tác lẫn nhau. Với khả năng lưu trữ và độ bảo mật cao, một tỷ lệ lớn các kho Git đều được lưu trữ trên Github và nhiều dự án mã nguồn mở khác.
  • 18. 7 Hình 7- Trang chủ Github Github là sự kết hợp giữa 2 từ Git và Hub mang ý nghĩa như sau: - Git: hệ thống quản lý dự án và phiên bản code - Hub: nơi biến những dòng lệnh trong Git thành một mạng xã hội Github kế thừa toàn bộ tính năng của Git, nhiều người nói rằng Git chính là trái tim của Github. Github được sử dụng chủ yếu cho dự án có nhiều người hợp tác, lên kế hoạch, cần giám sát toàn bộ thay đổi của dự án từ mức độ nhỏ đến lớn. Bên cạnh đó, nó còn khả năng khôi phục code khi cần thiết. Github trở thành yếu tố có sức ảnh hưởng lớn trong cộng đồng mã nguồn mở. Kết hợp với Linkedin, Github có thể xem như một CV cho các ứng viên muốn tìm kiếm việc làm. Việc tham khảo hồ sơ Github của ứng viên là một điểm cộng cũng như sự thú vị đối với các nhà tuyển dụng. Từ đây, kỹ năng sử dụng Git và Github trở thành điều kiện bắt buộc trong câu chuyện tìm việc làm thuộc giới CNTT. 1.3.2 Lịch sử và sự kiện của Github 1.3.2.1 Lịch sử Github ra đời nhằm cung cấp dịch vụ kho lưu trữ mã nguồn từ xa cho Git dựa trên nền tảng Web. Nền tảng được phát triển vào ngày 19 tháng 10 năm 2007 bằng ngôn ngữ Ruby và trang web được đưa vào hoạt động chính thức tháng 4 năm 2008 bởi Preston-Werner, Chris Wanstrath và PJ Hyett. Đến tháng 4 năm 2016, github có hơn 14 triệu người sử dụng với hơn 35 triệu kho mã nguồn. Vào tháng 3 năm 2018,
  • 19. 8 github trở thành dịch vụ máy chủ phổ biến dành cho mã nguồn mở. Vào ngày 4 tháng 6 năm 2018, github đã được thỏa thuận mua lại bởi Microsoft với giá 7.5 tỷ Đô la Mỹ. Hiện nay, với hơn 25 triệu người dùng và hơn 80 triệu mã nguồn dự án, Github đã trở thành một phần không thể thiếu đối với cộng đồng phát triển mã nguồn mở và cộng đồng lập trình viên trên toàn thế giới. 1.3.2.2 Sự kiện Lo sợ về thời điểm tận thế có thể xảy ra đến nhân loại bất cứ lúc nào, tạo mối nguy cho lượng dữ liệu khổng lồ do con người tạo ra hàng chục năm, Github đã đưa ra một dự án đang được giới công nghệ quan tâm với tên gọi Archive Program. Dự án có mục đích nhằm bảo tồn toàn bộ kho dữ liệu khổng lồ bằng cách chôn chúng một cách an toàn tại nơi tận cùng của Trái Đất đó là Bắc cực. Sau gần một năm kể từ thời điểm công bố, Giám đốc chương trình chiến lược Github, Julia Metcalf, đã thông báo cho biết bộ sưu tập mã nguồn mở trong nhiều thập kỉ của Github đã được gửi thành công 21 TB dung lượng mã nguồn vào kho chứa an toàn ngày 8 tháng 7 năm 2020 dù chậm tiến độ tới 5 tháng do ảnh hưởng của đại dịch COVID – 19. Hình 8- Dự án Arctic Code Vault Những dữ liệu bảo tồn ban đầu tổng cộng hơn 6.000 ứng dụng mã nguồn mở quan trọng, bao gồm mã nguồn cho hệ điều hành Android và Linux, cũng như ngôn ngữ lập trình, nền tảng Web, tiền mã hóa và các công cụ AI. Khối dữ liệu nằm chung với các tài liệu bảo tồn dưới dạng kỹ thuật số của các quốc gia nằm khắp nơi trên thế giới,
  • 20. 9 bao gồm các tác phẩm nghệ thuật, âm nhạc, các đột phá khoa học… Khối dữ liệu bảo tồn rất có ích trong trường hợp tận thế diễn ra, nó đóng vai trò là chiếc kén thời gian, lưu lại các giá trị hỗ trợ con người xây dựng lại nền văn minh công nghệ cho thế giới sau hậu tận thế. 1.3.3 Phân loại Github Github được xem là dịch vụ máy chủ Repository công cộng, nơi mọi người dễ dàng truy cập, khi các máy tính có thể clone lại một mã nguồn trên Repository lưu trữ tại Github. Người dùng cần tạo một tài khoản để sở hữu cho mình một kho chứa riêng. Github cung cấp dịch vụ này dưới 2 hình thức: miễn phí và tính phí. Github phiên bản có phí sẽ nhắm vào đối tượng là doanh nghiệp sử dụng để quản lý nhóm cũng như phân quyền bảo mật dự án. Phần lớn người dùng còn lại sẽ tạo tài khoản miễn phí để lưu trữ Source Code và chính điều này đưa Github tiếp cận đến nhiều đối tượng rồi trở nên phổ biến như ngày nay. Đến tháng 9 năm 2019, giá dịch vụ phiên bản trả phí của Github cụ thể như sau: - Github Individuals: bản cá nhân có giá từ 0 – 7$. Với gói Pro 7$, người dùng sẽ có nhiều tính năng hơn như: Draft pull requests, Code owners, Pages and wikis, Repository insights… cùng nhiều tính năng khác - Github Team: giá từ 9$ trở lên. Mức giá sẽ tăng tùy vào mô hình doanh nghiệp cần triển khai thông qua việc báo giá. Sử dụng gói dịch vụ với giá càng cao thì Github càng mang lại sự toàn diện Github cung cấp thêm tính năng mạng xã hội như Feeds, Follower và Network Graph tạo sự kết nối giữa các lập trình viên, cung cấp cho họ một cộng đồng để học hỏi kinh nghiệm lẫn nhau thông qua các các lịch sử Commit.
  • 21. 10 1.3.4 Tính năng API của Github API là từ viết tắt của Application Programming Interface – phương thức trung gian kết nối các ứng dụng và thư viện khác nhau. Việc sử dụng API tạo sự thuận tiện cho lập trình viên đẩy nhanh quá trình phát triển phần mềm, tạo ra sự nhanh chóng, nâng cao hiệu suất công việc. Ngoài Git thì API còn được xem là một tính năng quản lý khá toàn diện cho Github. Tính năng hỗ trợ lập trình viên và người dùng quản lý nguồn dữ liệu của mình hiệu quả và khoa học. Sau đây, nhóm em sẽ đưa một vài tính năng quan trọng của API trong Github: - API to Update The Repository via HTTP: Đây là tính năng khá đắt, cập nhật kho lưu trữ thông Web Browser, cho phép chỉnh sửa các tập tin mã nguồn thông qua giao thức HTTP – POST - API to Access Compare Views: Hỗ trợ người dùng so sánh Code với dự án qua việc xem Commit, Comments, đồng thời đưa ra nhận xét thông qua Web Browser - API to Manage Service Hooks: Cho phép người dùng đăng ký một đường dẫn URL cho các kho lưu trữ, khi có người đẩy lên Repo, Github sẽ thông báo thông qua URL này Ngoài ra, Github còn sở hữu nhiều tính năng API khác rất hay. Việc sơ lược về các tính năng này nhằm cho thấy sự tiện lợi của API trong Github.
  • 22. 11 1.3.5 Nền tảng làm việc của Github Quy tắc làm việc trên Github diễn ra trên hai nền tảng đó là Local Workflow và Server Workflow. Người dùng thay đổi Source Code ở Local rồi xác nhận sự thay đổi đó ở Server. Bản xác nhận phía Server phải là một phiên bản có chứa tính năng hoàn chỉnh hoặc có thể chạy được. Việc xác nhận các đoạn Code chưa hoàn chỉnh sẽ làm ảnh hưởng thành viên khác khi họ sử dụng chung kho lưu trữ. Từ kho lưu trữ này, người dùng có thể tạo các bản Build cho dự án gốc bằng cách gửi các Source Code có sự thay đổi lên đó. Với vấn đề bảo mật và kiểm soát quyền truy cập, mỗi người dùng khi sử dụng kho lưu trữ của Github phải cung cấp mã chứng nhận, có thể sử dụng một cặp khóa trong giao thức SSH, hệ thống sẽ so sánh SSH Key ở Local và trên Server tương ứng với Account nào đã được chính người dùng đó đăng kí. Các thao tác đối với hai nền tảng này của Github diễn ra thông qua các câu lệnh, thuật ngữ sẽ được nhóm em trình bày cụ thể ở tiêu đề 1.5 của bài báo cáo. 1.3.5.1 Thao tác với Repo ở Local Các thao tác dòng lệnh diễn ra ở Local hầu như đều là các dòng lệnh cơ bản của Git, trong đó, hai dòng lệnh nổi trội thường được nhiều đối tượng người dùng sử dụng là git add và git commit: - git add: thêm tập tin đã được thay đổi vào Stage - git commit: các tập tin trong Stage sẽ được đưa qua Repo của Local
  • 23. 12 1.3.5.2 Thao tác với Repo ở Server Khi người dùng hoàn tất tất cả quy trình, tạo ra một phiên bản ổn định của dự án ở Local, họ có thể quyết định cập nhật tập tin dự án đó lên Repo tại Server với ba câu lệnh sau là chủ yếu: - push: push các thay đổi từ Repo Local đến Repo Server - fetch: cập nhật thay đổi từ Repo Server về Repo Local - pull/rebase: sao chép Source Code từ Server về Local Workspace 1.4 Git 1.4.1 Sơ lược về Git Git là một đại diện tiêu biểu của hệ thống quản lý phiên bản phân tán DVCS mã nguồn mở, một trong những dạng hệ thống quản lý phiên bản phân tán phổ biến nhất hiện nay. Git có những đặc điểm sau: - Có hướng tiếp cận mới so với các hệ thống Source Control khác như SVN hay CVS truyền thống. - Có nhiệm vụ theo dõi những thay đổi, chỉnh sửa trong Source Code của người dùng vào mọi thời điểm và đồng bộ những Source Code do họ chỉnh sửa lên Server cùng đồng nghiệp. Ngoài ra, Git chạy được trên nhiều hệ điều hành khác nhau như Linux, Windows, MacOS… 1.4.2 Lịch sử Git Được xem là một sáng kiến hay và ra đời trong thời điểm xảy ra tranh chấp, git ra đời để thay thế BitKeeper vốn được dùng để chứa hàng ngàn dòng Code, bản vá và các tập tin của nhân Linux. Do mối quan hệ giữa nhóm lập trình viên phát triển nhân linux và công ty thương mại phát triển BitKeeper bị đổ bể dẫn tới bản thân BitKeeper bị thu hồi. Điều này dẫn tới cộng đồng phát triển nhân linux, bao gồm cả người tạo ra nó là Linus Torvards, tự phát triển một công cụ dựa trên những kiến thức được tiếp thu từ việc sử dụng BitKeeper. Git ra đời cùng với những yêu cầu được đề ra như sau: - Tốc độ - Thiết kế đơn giản
  • 24. 13 - Phân tán toàn diện - Phù hợp cho cả dự án lớn và nhỏ - Hỗ trợ mạnh mẽ cho hướng phát triển không tuyến tính Git sau đó phát triển mạnh mẽ, ảnh hưởng đến nhiều dự án lớn, và có cả một nhánh dành cho phát triển phi tuyến tính. Nhóm em xin tóm tắt quá trình hình thành Git qua các ý sau: - Git ra đời vào năm 2005 - Tác giả là Linus Torvald, đồng viết ra Linux kernel - Git vốn được phát triển để quản lý Source Code của Linux - Git trở thành phần mềm quản lý mã nguồn mở phổ biến và được phân phối theo giấy phép công cộng GPL2 1.4.3 Đặc điểm của Git 1.4.3.1 Tương tác dữ liệu với Git Đối với các VCS còn lại, git có hướng suy nghĩ khác biệt về dữ liệu. Hầu hết các hệ thống sẽ chứa thông tin như một danh sách các file được thay đổi, chỉ khi nào có một thao tác lưu lại “commit” thì chỉ duy nhất file thực thi lệnh đó mới được lưu trên server. Người dùng sẽ không thể thực hiện commit toàn bộ phiên bản trạng thái hiện tại, hệ thống sẽ ánh xạ đến lần lưu trữ file trước. Hình 9- Tương tác dữ liệu với các VCS Git xem dữ liệu như là một chuỗi “snapshot” của một hệ thống tập tin thu nhỏ. Mỗi lần người dùng “commit” hay lưu trạng thái của dự án, git sẽ chụp ảnh hết tất cả trạng thái phiên bản tập tin hiện tại và chứa nó như một tham chiếu đến snapshot đó. Khi file không thay đổi, Git sẽ tham chiếu đến lần lưu thông tin trước đó.
  • 25. 14 Hình 10- Tương tác dữ liệu với Git 1.4.3.2 Cơ chế Snapshot của Git Git lưu dữ liệu dưới dạng một ảnh chụp “Snapshot”, mỗi khi người dùng tiến hành lưu lại “commit” thì Git chụp lại hệ thống các file đó và lưu giữ một tham chiếu đến nó chỉ khi file có thay đổi, nếu không Git sẽ tham chiếu đến lần lưu trước đó. Hình 11- Mô tả cơ chế Snapshot 1.4.3.3 Thao tác Local của Git Mọi thao tác như thêm mới, xem lại lịch sử… với Git đều diễn ra tại cục bộ do mỗi máy trạm đều có một cơ sở dữ liệu Git. Ngoài ra, người dùng muốn đưa file dữ liệu lên một điểm lưu trữ khác hoặc muốn lấy file cập nhật của người khác thì lúc đó mới cần đến vai trò của server. Điều này giúp Git cải thiện tốc độ với việc sử dụng tài nguyên không đáng kể, bởi vì người dùng đã có toàn bộ dự án tại repo cục bộ của họ. Nó có ích cho người dùng khi họ Offline hay Off VPN, họ vẫn làm việc thoải mái và chỉ cần đợi trong điều kiện có mạng có thể up file lên. So với các hệ thống tập trung, họ sẽ không thể commit, push hay làm gì khi không kết nối tới cơ sở dữ liệu của server.
  • 26. 15 1.4.3.4 Định dạng đối tượng trong Git Git có một mục object được lưu trữ dùng để chứa file gốc và tất cả những tin nhắn log, chủ nhân file, ngày tạo và thông tin khác cần để tạo nên một sửa đổi hay nhánh cho dự án. Có 3 thành phần quan trọng của object cần chú ý: type, size, content. - Size: đơn giản là kích cỡ của nội dung - Content: dựa vào type (loại) của đối tượng - Type: loại đối tượng được chứa trong đường dẫn .git/objects, gồm 4 loại khác nhau, bao gồm: • blob: dùng để lưu file dữ liệu – là tập tin nhị phân của mỗi phiên bản file, đây còn là nguyên nhân dẫn đến sự gia tăng dung lượng kho chứa • tree: đơn giản là một đường dẫn • commit: giữ metadata cho mỗi lần file thay đổi trong kho lưu trữ, bao gồm chủ sở hữu, người gửi, dữ liệu commit, thông điệp nhật ký • tag: gán một tên có ý nghĩa mà người dùng đọc được cho một đối tượng cụ thể khi sử dụng commit Có một khái niệm liên quan đến cơ chế Snapshot của Git là loose object format (định dạng đối tượng trong suốt của git). Để thấy được thư mục đối tượng, người quản trị tạo 3 file lần lượt là 0.txt, 1.txt, 2.txt và sử dụng các lệnh commit, trong folder sẽ xuất hiện file .git. Git tạo 3 thư mục trong đường dẫn .git/objects lần lượt là 53, ab, e6
  • 27. 16 Trong mỗi thư mục sẽ có chứa một file mã băm gồm 40 kí tự với 2 kí tự là tên gọi của thự mục đường dẫn, 38 kí tự còn lại được dùng như tên file, người dùng gõ lệnh “git cat-file [-option] [ten_file]”, option được chọn ở đây là [-t] *Lưu ý: ten_file phải bao gồm đủ 40 kí tự, tức là bao gồm cả 2 kí tự tên thư mục đường dẫn Chỉnh sửa nội dung tập tin, Git sẽ tạo thêm 5 tập tin trên những tập tin cũ Thông qua câu lệnh git cat-file [-t], các thư mục băm với hai ký tự đầu sẽ được hiển thi rõ ràng nội dung cũng như tính năng tương tự
  • 28. 17 Bất cứ khi nào người dùng commit, git đều chụp lại vào ổ đĩa giữa phiên bản cũ và phiên bản mới trong cùng một file, kể cả ta chỉ thay đổi một kí tự nội dung file. 1.4.3.5 Tính toàn vẹn của Git Mọi thứ trong Git đều được kiểm tra “checksummed” trước khi được lưu trữ và được tham chiếu bởi Checksum này. Chức năng này cho Git biết mọi sự thay đổi trong một file hay một đường dẫn, nó bảo đảm tính toàn vẹn giúp người dùng không thể mất thông tin trong trường hợp trao đổi dữ liệu hay file lỗi không thể nhận ra. Một sự thật là Git đã lưu cơ sở dữ liệu không phải bởi tên file mà là giá trị hàm băm của chính nội dung file đó. Hàm băm Git sử dụng là SHA - 1, gồm 40 kí tự được tạo ra theo nội dung của file có độ dài 40 ký tự, được tích hợp ở tầng thấp nhất của Git và là một triết lý không thể thiếu của nó. Nó còn được xem là một “commit id”. Một ví dụ điển hình của hàm băm SHA - 1, ta sẽ thực hiện các lệnh sau: - “git show -s --format=%h” với kí tự ‘H’ là xem phiên bản đầy đủ - “git show -s --format=%h” với kí tự ‘h’ là xem phiên bản rút gọn của hàm băm Hình 12- Hàm băm trong Git
  • 29. 18 1.4.3.6 Tính dễ dàng trong Git Git đơn giản chỉ thêm dữ liệu vào cơ sở dữ liệu Git, khó làm cho hệ thống làm một việc gì đó mà không phục hồi lại được cũng như không thể xóa hoàn toàn dữ liệu khỏi hệ thống. Điều này khiến Git trở nên thú vị đối với những người dùng thích trải nghiệm mà không sợ những mối nguy làm hại hệ thống, vì Git chứa dữ liệu đó và giúp người dùng phục hồi nó. 1.4.4 Ưu và nhược điểm của Git Dựa vào những đặc tính và sự phổ biến của Git đối với người dùng, nhất là lập trình viên, ta sẽ đưa ra những lợi ích khi sử dụng Git. Tuy nhiên, một công cụ hay phần mềm nào cũng đều có lợi và hại. Vậy Git có nhược điểm gì và nó có độ ảnh hưởng như thế nào tới công việc mà người dùng vẫn bỏ qua và sử dụng Git? Hình 13- Website Trustradius đánh giá Git Để biết được hai điểm này, ta sẽ phải tham khảo thông qua những đánh giá của người dùng Git trên các diễn đàn, trang báo mạng do họ đã trải nghiệm sản phẩm, có thể là ít hoặc lâu dài, họ dành thời gian cho Git, nắm rõ được những tiện lợi của Git, đồng thời biết đến một vài bất tiện của nó. Tổng hợp, nhóm em sẽ tổng hợp những đánh giá trên website: https://www.trustradius.com/ để thấy được những ưu/nhược điểm của Git.
  • 30. 19 1.4.4.1 Ưu điểm Đa phần người dùng đều đánh giá, trong vô số công cụ thì Git lại là một “ông vua” thuộc mô hình DVCS. Họ đã khẳng định việc đó dựa vào những ưu điểm của Git, điều đã giúp nó trở thành công cụ phổ biến nhất hiện nay: - Mô hình phân tán – làm việc tại Local, không công khai, tốc độ phản hồi nhanh chóng, làm việc offline, truy cập mọi nơi, backup - Chia nhánh và gộp dễ dàng – có thể làm việc trên một nhánh riêng, tiết kiệm, nhanh và không chiếm nhiều dung lượng, khi xong ý tưởng riêng có thể gộp lại với nhánh chính - Quy trình làm việc linh hoạt – cho phép người dùng tạo một một quy trình làm việc riêng “Workflow” phù hợp, từ một quy trình chính phân ra các quy trình phụ - Đảm bảo toàn vẹn dữ liệu – quản lý dự án tuyệt vời bằng việc sử dụng cây hàm băm SHA-1, dữ liệu bị gián đoạn có thể bị phát hiện - Tích hợp trong nhiều công cụ khác - Mã nguồn mở, giúp tiết kiệm chi phí cho chủ doanh nghiệp - Cho phép một dự án có nhiều thành viên, tổ chức cùng code, testing kể cả ở cách xa nhau - Nhiều tài liệu và quy trình, cộng đồng hỗ trợ - Có giao diện dòng lệnh trực quan, dễ học và mở rộng khả năng, có thể triển khai dự án chỉ với một vài câu lệnh cơ bản, có nhiều tool dòng lệnh rất mạnh hỗ trợ người dùng cuối 1.4.4.2 Nhược điểm Bên cạnh những ưu điểm vượt trội trên, Git cũng tồn tại những vấn đề bất cập gây khó chịu cho người dùng. Đó chính là những nhược điểm sau đây: - Không có cách nào để tránh tải toàn bộ lịch sử commit của một dự án, nếu dự án có nhiều Module và Package thì đây là một vấn đề lớn - Hàm băm SHA – 1 trong kho Git xuất hiện nhiều điểm yếu do sự va chạm giá trị băm, một máy tính thông thường có thể âm thầm phá hủy giá trị băm này - Quá trình học sử dụng Git khá phức tạp, vài câu lệnh có Option không trực quan đòi hỏi người sử dụng phải có hiểu biết về quá trình hoạt động bên trong của Git, nhiều câu lệnh và cú pháp không đồng nhất ở vài cấp bậc
  • 31. 20 - Nếu dự án không có file dạng văn bản thì cập nhật thường xuyên sẽ làm Git giải quyết cồng kềnh và chậm chạp - Thiếu nhiều công cụ hỗ trợ giao diện cho Git Client 1.5 Các khái niệm trong Git và Github Trong Git và Github tồn tại nhiều thuật ngữ đòi hỏi người sử dụng, đặc biệt là những người dùng mới, phải làm quen, đọc nhiều tài liệu, tham khảo các trang mạng mới biết được ý nghĩa và công dụng của nó. Nhóm em sẽ trình bày những thuật ngữ cần quan tâm trong bài như sau: Repository: viết tắt là Repo, thường được xem là một dự án, một kho chứa chính cho toàn bộ mã nguồn lệnh, tập tin, thư mục có nội dung cần cho dự án trong hệ thống quản lý Version. Có thể xem nó là một đối tượng cơ sở dữ liệu chứa tất cả mọi thứ từ phiên bản, các phiên ủy thác, lịch sử thay đổi của nội dung và không giới hạn cho người chia sẻ và sao chép. Git chia Repo thành 2 loại mô tả thông qua hình sau: Hình 14- Local Repo và Remote Repo - Local Repository: thao tác trên máy tính cá nhân người dùng hoặc server phát triển ở vùng Local, dành cho người dùng sử dụng không cần Internet - Remote Repository: (tên gọi mặc định là Origin) nằm ngoài, thao tác thông qua Local, thao tác nhiều người dùng. Khi muốn chia sẻ nội dung công việc đã
  • 32. 21 làm ở Local thì ta sẽ tải lên Remote Repo để công khai nội dung công việc đó. Có 2 hệ thống Remote được sử dụng nhiều là Github và Bitbucket Working tree: (viết tắt là Tree) được xem là nhánh, chỉ mục làm việc hiện tại, nơi người dùng chỉnh sửa, tạo file mới. Index: nơi bảo trì trạng thái sau khi chỉnh sửa trên Working Tree, là đối tượng nằm giữa Repo và Tree, đưa tập tin thay đổi commit lên Repo. Branch: phân nhánh và ghi chép lịch sử, có 3 loại nhánh: - Local Branch: Branch quản lý trong Local Repository - Remote Branch: Branch trong Remote Repository - Remote Tracking Branch: Branch để Local Repository theo dõi Remote Branch Checkout: triển khai Branch ở Repo lên Tree, chuyển từ một nhánh sang một nhánh khác. Merge: trộn 2 hay nhiều Commit từ một nhánh khác vào nhánh hiện tại. Hình 15- Minh họa hành động Merge Conflict: đây là trường hợp có 2 sự thây đổi Code cùng lúc làm máy tính không xác nhận được Code “cần”. Lúc này, lập trình viên phải chỉnh tay thủ công, xóa bỏ dòng Code không cần thiết, một số IDE có hỗ trợ Extension cho phép ta chọn dòng Code ta cần xóa bỏ. Tag: tên được gắn thêm vào file để dễ dàng tham chiếu Commit. Commit: đây là những hành động thêm/thay đổi file hay thư mục vào Repo. Repository lúc này sẽ tạo ra commit (hoặc revision) để ghi lại sự khác biệt từ trạng
  • 33. 22 thái commit lần trước với trạng thái hiện tại. Các commit được chứa tại repo nối tiếp nhau theo thứ tự thời gian. Hình 16- Minh họa hành động Commit *Trong Commit sẽ có 2 trạng thái cần lưu ý: - Tracked: tập tin được đánh dấu theo dõi trong Git để người dùng làm việc, gồm thêm các trạng thái phụ khác là Unmodified (chưa chỉnh sửa), Modified (đã chỉnh sửa) và Staged (đã sẵn sàng để commit) - Untracked: tập tin còn lại mà người dùng không muốn làm việc với nó trong Git Staging: bất cứ khi nào người dùng thực hiện commit thì Git sẽ tìm kiếm file trong khu vực tổ chức (Staging Area) và chỉ những file trong khu vực này mới được xem xét để commit. Hình 17- Minh họa các hoạt động của Staging Revision: giá trị hash được tạo mỗi lần commit, do Git quản lý theo thế hệ. HEAD: là một điểm con trỏ, trỏ vào Commit mới nhất trong nhánh.
  • 34. 23 *Ngoài ra, Git còn hỗ trợ thêm các câu lệnh sau cho người dùng tương tác với hệ thống Git. Clone: đây là hành động tải xuống bản sao của một Repository Local, quá trình này cần kết nối Internet khi các Repository Instance đang được đồng bộ từ các Remote Repository. Fetch: tải về (fetch) dữ liệu của toàn bộ các Branch trên URL nhưng không thực hiện merge các thay đổi vào Local. Pull/Pull request: tải về (fetch) dữ liệu từ một Branch duy nhất từ Remote server và sau đó merge các thay đổi từ Remote này về Local Repository (đồng bộ từ Git server tới máy khách). Push: thao tác đẩy các thay đổi bản sao chép từ Repository Local lên Remote Repository, sử dụng để lưu thay đổi vĩnh viễn trong Repo Git, tương tự như commit. 1.6 Git Remote Server Hình 18- Công dụng Git Remote Server Ở mục tiêu đề này nhóm em muốn giới thiệu tổng quát về các giao thức được sử dụng đối với Git trên server cũng như công dụng của server đối với Git. Git server đơn giản đóng vai trò làm một máy chủ cài đặt Git, cho phép tạo Repository. Đơn cử là Github, Gitlab… sau đó cho phép người dùng “clone” nội dung về Local và có thể cập nhật lên lại Remote. Nó được xem như một Repo đứng giữa để nhiều người dùng,
  • 35. 24 thành viên dự án cùng đăng nhập vào, kể cả đang offline hay online, thực hiện push và pull dữ liệu qua nó. Hầu hết các thao tác làm việc của git đều xuất hiện ở local (máy client) với local repository, chỉ khi nào người dùng có nhu cầu làm việc nhóm hay đơn giản muốn làm ở nhiều máy khác nhau thì họ sẽ sử dụng đến remote repository hay còn gọi là repository ở phía server. Sử dụng Git như một server sẽ dễ kiểm soát cũng như phân quyền dễ dàng để quản lý các thành viên, khách hàng trong một dự án, luôn đảm bảo mức bảo mật cho dự án. Về phía các giao thức sử dụng hỗ trợ phía server, người dùng có thể dùng nhiều giao thức khác biệt để truyền dữ liệu: Local, HTTP, SSH và Git. 1.6.1 Giao thức Local Là giao thức cơ bản nhất trong số các giao thức Git trên server. Nó tạo một remote repository ở một đường dẫn khác trong cùng một host và dành cho nhóm người dùng muốn đăng nhập vào một hệ thống chia sẻ tập tin như NFS mount, hay như trường hợp mọi người cùng đăng nhập vào một máy tính. Người dùng có thể thực hiện các lệnh clone, push, pull từ local repository, một trường hợp clone từ local repo của người dùng. Hình 19- Đường dẫn URL của Local Repo Người dùng gõ thẳng đường dẫn của chính file đó để ít ảnh hưởng đến tốc độ của git. Để thêm Local Repo vào một dự án đang thực hiện, người dùng gõ lệnh như sau: Với local_proj là tên Local Repo Ưu điểm: dễ dàng, chỉ cần truy cập một file đã tồn tại được phân quyền và có hỗ trợ mạng internet, dễ dàng chuyển giao công việc cho người bên ngoài nhóm vào làm việc.
  • 36. 25 Nhược điểm: thiết lập truy cập chia sẻ khó khăn đối với môi trường có nhiều nơi cần truy cập, chia sẻ phân vùng không phải cách nhanh nhất, mọi người dùng đều có quyền shell cao nhất nên có thể chỉnh sửa file bên trong hay làm gián đoạn repo. 1.6.2 Giao thức HTTP Git giao tiếp với HTTP qua 2 phương thức, cũ nhất sẽ là Dump HTTP và mới nhất là Smart HTTP. 1.6.2.1 Smart HTTP Giao thức này hoạt động giống như SSH hay những giao thức của git, có cổng HTTPs chuẩn và dùng nhiều phương pháp HTTP chứng thực khác nhau. Sau đây là một vài đặc điểm: - Dễ dàng cho người dùng truy cập bằng phương pháp chứng thực username/password hơn là thiết lập key cho phiên SSH - Là cách để sử dụng git phổ biến nhất hiện nay, có thể phục vụ cho cả giao thức git:// - Có thể đẩy lên bằng phương pháp chứng thực và mã hóa như giao thức SSH, nếu repo yêu cầu chứng thực, server sẽ yêu cầu quyền username/password để truy cập - Phục vụ cả hai phương thức trên chỉ bằng một URL 1.6.2.2 Dump HTTP Nếu server không phản hồi với giao thức Smart HTTP, Git Client sẽ cố gắng sử dụng lại giao thức đơn giản Dump HTTP. Giao thức xem bare git repo như là một tập tin thông thường trên máy chủ web. Giao thức rất dễ cài đặt, người dùng chỉ cần đặt bare git repo trong một thư mục HTTP root và một hook cập nhật cụ thể. Bất cứ thành viên nào có quyền dưới web server đều có thể clone Repository. Để cấp quyền cho Repo bởi giao thức HTTP, chỉ cần vài lệnh sau: Sau đó, để chạy hook cập nhật, người dùng chỉ cần chạy một câu lệnh thích hợp là (git-update-server-info) để khiến git fetch và cloning công việc ngay lập tức, chỉ
  • 37. 26 xảy ra khi người dùng muốn push tới repo đó hoặc muốn clone thứ gì đó như câu lệnh sau: Ưu điểm: - Đơn giản vì chỉ cần một URL cho mọi loại truy cập và có server điều khiển chứng thực khi cần - Có thể chứng thực thông qua username/password giúp người dùng không phải qua thao tác tại key giữ bí mật và đưa key công khai lên server một cách rắc rối - Nhanh và hiệu quả Nhược điểm: - Thiết lập có thể trở nên khó khăn ở vài server so với SSH - Việc cung cấp thông tin đăng nhập đôi khi lại trở nên khó khăn, mặc dù có vài công cụ hỗ trợ đăng nhập với caching 1.6.3 Giao thức SSH Giao thức vận chuyển nổi tiếng của git khi tự hosting chính nó là SSH. Giao thức này được cài đặt ở hầu hết server. Nó đồng thời cũng là một giao thức chứng thực mạng và bởi tính phổ cập của nó nên rất dễ dàng thực hiện thiết lập và sử dụng. Để clone Git Repository thông qua SSH, ta chỉ cần sử dụng URL đặc trưng ssh:// như sau: Người dùng có thể sử dụng cú pháp ngắn gọn hơn như sau: Ưu điểm: - Giao thức phổ biết, dễ dàng cài đặt - SSH daemon lại phổ biến, được nhiều nhà quản trị mạng có kinh nghiệm sử dụng - Được cài sẵn trên nhiều hệ điều hành phân phối và có công cụ để quản lý - Truy cập bảo mật, mọi dữ liệu đều được mã hóa và đã được chứng thực - Ảnh hưởng tích cực đến các giao thức khác như HTTPs, Git và các giao thức Local
  • 38. 27 Nhược điểm: - Không hỗ trợ truy cập ẩn danh vào Git repo - Nếu hệ thống sử dụng SSH, người dùng phải có cài tính năng SSH truy cập vào, không phù hợp với những dự án mã nguồn mở - Khi cài đặt SSH trong hệ thống, chỉ có thể sử dụng nó khi push dữ liệu và phải xài công cụ, giao thức khác để fetch dữ liệu về 1.6.4 Git daemon Được đính kèm với các package cùng git, nó lắng nghe ở cổng mặc định là 9418 cung cấp một dịch vụ giống như giao thức SSH nhưng không có chứng thực. Muốn sử dụng, người dùng phải tạo một file git-daemon-export-ok bởi vì daemon sẽ không phục vụ khi không có file trong đó, tuy nhiên nó lại không được bảo mật. Bất cứ ai tìm thấy địa chỉ URL project của bạn đều có thể push vào đó. Ưu điểm: - Là giao thức internet nhanh nhất - Phù hợp cho nhu cầu có một dự án public hay một dự án lớn không cần phương pháp xác thực - Sử dụng chung phương pháp vận chuyển dữ liệu giống SSH nhưng không mã hóa và xác thực Nhược điểm: - Yếu tố không xác thực - Khó cấu hình thiết lập, yêu cầu phải chạy trên đúng daemon chính nó nên phải cài đặt xinetd hay systemd - Phải chỉnh tường lửa mở cổng mặc định 9418, do không phải là port tiêu chuẩn nên thường bị chặn 1.7 Bài toán dung lượng trong Git Bản thân Git là một hệ thống kiểm soát phiên bản phân tán nên có một nhược điểm là khó quản lý các tệp nhị phân dung lượng lớn do tất cả các hành động Clone lấy về đầy đủ phiên bản, lịch sử của Repo. Bản thân các dữ liệu trong Repo đạt đến dung lượng lớn, trường hợp này người dùng chỉnh sửa file và mỗi lần Commit sẽ lưu lại toàn bộ file trong Repo. Sau vài lần lặp lại, kho lưu trữ cục bộ sẽ nhanh chóng chứa hàng tấn Megabytes và cuối cùng là Gigabytes.
  • 39. 28 Hình 20- Nhiều Commit tăng dung lượng Repo 1.7.1 Git đóng gói Như trường hợp trên, nếu tổng lượng file lớn, nhiều bản Snapshot dẫn tới Git chiếm dụng một lượng lớn bộ nhớ hơn cả VCS. Nhưng Git đã có sẵn một cơ chế khắc phục đó chính là câu lệnh “git gc”, một lệnh duy trì kho, với “gc” viết tắt của bộ sưu tập rác trong Git. Hình 21- Mô tả lệnh git gc Người dùng thực hiện lệnh “git gc”
  • 40. 29 Công dụng của nó như sau: - Nén các đối tượng git được lưu trữ. Khi xác định được một nhóm đối tượng, git sẽ nén chúng thành một gói “pack” - Lưu chúng thành một file giống tệp zip có đuôi .pack nằm trong đường dẫn .git/objects/pack - Xóa những bản chụp có nội dung giống nhau để thu nhỏ kích thước của chính nó để giải phóng không gian ổ đĩa - Không xóa các xác nhận đã tách rời để bảo tồn lịch sử phiên bản và tránh mất dữ liệu Git gc được thực hiện thủ công tương ứng với mức độ hoạt động của một kho lưu trữ, nhất là một kho được đóng góp bởi một nhà phát triển và nó được chạy tự động khi những lệnh sau được thực thi: git pull, git merge, git rebase, git commit. Cấu hình chỉnh sửa lại những giá trị của câu lệnh để làm rõ chức năng của nó: • Thiết lập thời gian lưu trữ các bản ghi trong một nhánh (mặc định là 90 ngày) • Thiết lập thời gian lưu trữ hồ sơ reflog không thể truy cập được (mặc định 30 ngày) • Kiểm soát thời gian dành cho giai đoạn nén delta của việc đóng gói đối tượng (mặc định là 250) khi git sử dụng option [-aggressive] • Kiểm soát độ sâu của việc sử dụng nén khi sử dụng câu lệnh git với tùy chọn [-repack], còn git [-aggressive] thì thực hiện (mặc định là 50)
  • 41. 30 • Đặt thời gian một vật thể không thể tiếp cận sẽ được bảo quản trước khi cắt tỉa (mặc định là 2 tuần trước đó) • Đặt thời gian cho một cây làm việc cũ được bảo tồn trước khi bị xóa (mặc định là 3 tháng) 1.7.2 Git LFS Git LFS (Large File Storage) là một tiện ích mã nguồn mở cung cấp cơ chế xử lý các phiên bản file lớn lưu trữ. Nó có nhiệm vụ thay thế các file lớn như audio, video, dataset hay graphics với con trỏ text bên trong Git, trong khi chứa các file nội dung trên remote Server như Github. LFS không được tích hợp sẵn trong Git, tuy nhiên về phía Server như Github, Gitlab, Bitbucket, công cụ lại được hỗ trợ mạnh mẽ đến nỗi người dùng không cần lo lắng về cách triển khai nó trên Server phức tạp ra sao. Đây là một giải pháp hiệu quả vì LFS hoạt động trong suốt đối với quy mô dự án sẵn có của người dùng, không làm gián đoạn quy trình làm việc dự án. Hình 22- Công cụ Git LFS LFS bao gồm các tính năng: - Chứa phiên bản file lớn: Version Large Files – thậm chí lớn tới gấp đôi kích cỡ GB - Nhiều không gian Repository: lưu trữ file bên ngoài Repo gốc sẽ giúp người dùng giữ kho lưu trữ ở khoảng dung lượng vẫn còn kiểm soát được
  • 42. 31 - Cloning và fetching nhanh hơn: tải về ít dữ liệu hơn – do Repo hiện tại không còn chứa dữ liệu lớn - Quy trình làm việc như Git: không cần bất cứ dòng lệnh nào khác, LFS giống dòng lệnh của Git tạo sự thích nghi nhanh chóng đối với người dùng - Phân quyền và điều khiển truy cập: giữ phân quyền và kiểm soát cho các file lớn giống như các file còn lại của Git Repo khi làm việc với Remote Host Git LFS có cơ chế thay thế tất cả file dung lượng lớn trong Repository bằng những con trỏ tượng trưng nhẹ hơn với vài Bytes. Mỗi con trỏ sẽ tham chiếu đến các file lớn khi chúng được lưu trữ cùng với Repo nhưng nằm bên ngoài vùng Stag. Khi người dùng sử dụng lệnh push, file lớn sẽ được truyền vào nơi chứa LFS (LFS Store được nhúng trong Github) và phần Stag sẽ được truyền vào Repo của Github như thông thường. Repository của người dùng sẽ chỉ nặng thêm vài Bytes khi họ thay đổi một file lớn. Khi người dùng pull để lấy dữ liệu vùng Stag từ Github về như bình thường, sử dụng lệnh commit sẽ thay thế con trỏ thành chính file lớn liên quan tham chiếu từ nơi chứa LFS. Điều đó thể hiện người dùng chỉ tải về phiên bản các file mà họ muốn làm việc cùng chứ không phải mỗi phiên bản như trước. Lập trình viên khi làm việc với LFS không thấy những file con trỏ trên ổ đĩa của họ vì Git LFS sẽ tự động ngắt khỏi vùng Staging khi nhận thấy sự thay đổi của dữ liệu hoặc khi lập trình viên quay lại lệnh commit trước đó. Người lập trình không cần phải học thêm bất cứ câu lệnh nào khác từ Git LFS.
  • 43. 32 CHƯƠNG 2: CÀI ĐẶT GIT 2.1 Các môi trường Git hỗ trợ Git hỗ trợ nhiều nền tảng, có cả 3 nền tảng phổ biến với người dùng: Windows, Linux, MacOS. Do không có thiết bị chạy hệ điều hành MacOS, nhóm xin thực hiện demo các bước cài đặt trên 2 nền tảng còn lại là Windows và Linux. Người dùng tải file cài đặt hoặc clone Source Code từ trang web chính thức của Git cho 3 nền tảng qua đường dẫn sau: https://git-scm.com/downloads Hình 23- Website tải Git chính thức của nhà phát hành 2.1.1 Trên Linux Hệ điều hành Linux hỗ trợ Git rất tốt, đặc biệt là với công cụ Terminal mặc định của Linux, giúp Git phát huy được tối đa sức mạnh vốn có. Git sẽ có nhiều cách cài khác nhau dựa trên từng Distro từ nhân Linux. Người dùng cần truy cập vào trang chủ của Git, làm theo hướng dẫn với đường dẫn sau: https://git- scm.com/download/linux Bước 1: Mở terminal và gõ 2 lệnh sau Bước 2: Gõ lệnh ‘git –version’ để kiểm tra đã cài đặt thành công
  • 44. 33 2.1.2 Trên Windows Windows vốn là hệ điều hành quen thuộc với đại đa số người dùng. Việc Git hỗ trợ cho hệ điều hành quốc dân này tạo nhiều điều kiện đa dạng cho người dùng, nhất là lập trình viên chọn lựa làm việc trên hệ điều hành họ thích. Để cài Git trên Windows, người dùng cài công cụ giả lập Terminal. Bước 1: Truy cập vào đường dẫn https://gitforwindows.org/ Hoặc tải từ trang chủ: https://git-scm.com/download/win Bước 2: Tải xuống một file *.exe, nhấn chuột vào file để tiến hành cài đặt
  • 45. 34 Bước 3: Cài đặt bình thường như các phần mềm khác có hỗ trợ giao diện cho Windows, dựa vào yêu cầu của mỗi người dùng mà chọn lựa cho phù hợp Bước 4: Bước tiếp theo là cài git editor cho windows, có thể là các text editor như vim, notepad++, sublime text,… Hình 24- Lựa chọn Sublime Text làm Git Editor Bước 5: Tiếp theo, lựa PATH môi trường thích hợp với nhu cầu
  • 46. 35 Bước 6: Chọn phong cách dòng lệnh như thế nào Bước 7: Bấm install để cài đặt
  • 47. 36 Bước 8: Cài đặt thành công Bước 9: Gõ lệnh git version để kiểm tra phiên bản cũng như Git đã cài đặt thành công
  • 48. 37 Sau khi cài đặt, do tùy chọn ở bước 5, công cụ Git sẽ xuất hiện hai tệp chạy chương trình, mỗi tệp ứng với một môi trường. Tệp git-bash sẽ dành cho người dùng quen thuộc với hệ thống kiến trúc hệ điều hành Unix/Linux. Tệp git-cmd còn lại phù hợp cho những người dùng quen thuộc với MS – Dos, vốn là các lệnh được tích hợp trong Command Prompt (CMD) của hệ điều hành Windows. Hình 25- Hai chương trình khởi chạy ứng với hai môi trường 2.1.3 Phiên bản GUI Ngoài ra, người dùng còn có thể tải về phiên bản Graphical User Interface (GUI) dành cho Git, hỗ trợ trên cả 3 nền tảng cung cấp giao diện để người dùng thao tác dễ dàng, giúp họ không gặp khó khăn với vấn đề học cách sử dụng dòng lệnh Sẽ có rất nhiều phiên bản GUI bao gồm miễn phí, trả phí, tích hợp tính năng khác để phục vụ tốt hơn. Truy cập đường dẫn sau để tải về phiên bản giao diện của Git: https://git-scm.com/download/gui/windows Hình 26- Công cụ bên thứ 3 hỗ trợ GUI cho Git
  • 49. 38 CHƯƠNG 3: TRIỂN KHAI 3.1 Cấu hình Github Để tương tác sử dụng Git trong các công việc, dự án về Code, sau đó đưa nó lên các kho lưu trữ Code như Github, Gitlab…. Ở đây, liên quan đến tên đề tài, nhóm em lựa chọn Github để thực hiện. Muốn sử dụng Github, điều đầu tiên yêu cầu mỗi người dùng là tạo một tài khoản sử dụng. Github hỗ trợ tính năng này miễn phí và dễ dàng cho nhiều người tiếp cận. Người dùng điền đầy đủ thông tin rồi nhận Mail kích hoạt. Hình 27- Nơi đăng ký tài khoản Github Sau khi kích hoạt tài khoản thành công, người dùng sẽ được tương tác trực quan qua giao diện Web với kho lưu trữ Github như tạo Repo dự án ban đầu, chia nhánh và phối hợp với Git như một Server. 3.1.1 Tạo Github Repository Để làm việc, trước hết cần tạo một kho lưu trữ mã nguồn lệnh cho dự án, việc này về bản chất cũng giống như thao tác trên các dòng lệnh Git, ở đây, người dùng sẽ làm qua giao diện với các cú nhấp chuột. Các bước tạo Repo ban đầu được mô tả như sau:
  • 50. 39 Bước 1: Người dùng bấm vào ký hiệu dấu cộng bên cạnh ảnh đại diện của tài khoản và chọn New repository, Github sẽ chuyển qua trang khởi tạo Repo mới Hình 28- Khởi tạo Github Repositories Bước 2: Đặt tên cho Repo cũng như miêu tả dự án nếu cần thiết Hình 29- Đặt tên cho Repo Hình 30- Mô tả Repo dự án Bước 3: Chọn một trong hai tùy chọn do Github đưa ra. Hai tùy chọn có nội dung như sau: - Hai chế độ phân quyền là Public và Private. Public là chế độ mặc định, cho phép bất cứ ai cũng có thể xem được Repo. Nếu người tạo không muốn công khai có thể chuyển sang chế độ Private Hình 31- Hai chế độ phân quyền của Repo Github
  • 51. 40 - Tập tin README giới thiệu Repo kèm một tập tin .gitignore. Đây là một template có sẵn trong Github và cho mọi người tùy chọn Hình 32- Template tùy chọn Repo Github Bước 4: Bấm nút Create repository tạo Repo, Github sẽ chuyển trang Repo đã hoàn thành *Trường hợp, người dùng không thêm tùy chọn, Github sẽ mặc định đây là người dùng mới với dịch vụ nên nó sẽ chuyển đến một trang hướng dẫn cho người dùng này.
  • 52. 41 Khi đã có Repository, người dùng có thể clone, pull, push… mã nguồn lệnh dự án của mình lên đó. Phần tiếp theo, nhóm em sẽ tìm hiểu về Branch trên Github. 3.1.2 Tạo Github Branch Nguyên nhân ra đời cũng như tổng quát về Branch (nhánh) sẽ được nhóm giải thích chi tiết ở nội dung “Cấu hình Git nâng cao”. Ở Github, việc tạo nhánh trải qua hai bước đơn giản. Bước 1: Người dùng chọn vào mũi tên trỏ xuống tại mục Branch trên giao diện Web Bước 2: Đặt tên Branch để hiển thị nút tạo Hình 33- Đặt tên nhánh trên Github Bước 3: Ấn tạo bằng dòng Create branch: [tên_nhánh], kết quả là nhánh tạo thành công
  • 53. 42 Hình 34- Repo hiện có 2 nhánh 3.1.3 Sử dụng Github Github có đầy đủ dòng lệnh của Git, do yêu cầu đề tài chuyên sâu về Git nên nội dung phần này sẽ chỉ bao quanh 3 câu lệnh cấu hình Github cơ bản nhất. Ba câu lệnh mô tả cả một quy trình làm việc của Github. Các câu lệnh khác sẽ được đề cập cụ thể trong các phần cấu hình Git. 3.1.3.1 Lệnh Commit trên Github Câu lệnh Commit cho phép lưu lại thay đổi của file cùng tin nhắn mô tả rõ ràng cho phép quản lý, theo dõi dự án tốt hơn. Để commit, người dùng làm như sau: Bước 1: Chọn file muốn sửa Bước 2: Nhấn ký hiệu Edit để sửa file Bước 3: Sửa nội dung file “Day la danh cho muc dich hoc tap!!” Bước 4: Để lại lời nhắn và nhấn Commit changes
  • 54. 43 3.1.3.2 Lệnh Pull trên Github Câu lệnh quan trọng trên Github, cho biết những thay đổi trong Source Code, yêu cầu chủ sở hữu xem xét, hỗ trợ mọi người đóng góp công sức vào dự án. Tránh sự nhầm lẫn về lệnh Pull, nhóm sẽ làm rõ hơn câu lệnh này: - Lệnh Pull Request: yêu cầu chủ sở hữu xem xét thay đổi trước khi gộp vào nhánh chính - Lệnh Pull: lệnh đơn thuần của Git để nâng cấp dữ liệu từ server về Local, có thể xảy ra xung đột Bước 1: Vào tab Pull requests và nhấn New pull request Bước 2: Chọn file cần thiết Bước 3: Xem sự khác nhau giữa hai lần commit
  • 55. 44 Bước 4: Bấm tạo Create pull request và hoàn thành câu lệnh Hình 35- Tạo pull request trên Github 3.1.3.3 Lệnh Merge trên Github Lệnh hợp nhất các nhánh trên Github trải qua các bước sau: Bước 1: Bấm nút Merge pull request để hợp nhất những thay đổi vào nhánh Master Bước 2: Xác nhận gộp nhánh Master và hoàn thành Bước 3: Github đưa ra tùy chọn xóa nhánh sau khi gộp thành công
  • 56. 45 3.1.4 Xóa Github Repository Nếu có nhu cầu xóa Repo thì yêu cầu tài khoản người dùng phải có đặc quyền hoặc là Admin cho một Repo của tổ chức. Các bước xóa Repo trên Github rất đơn giản nhưng có một vài điều cần lưu ý là tất cả các tệp đính kèm cùng phân quyền nhóm dự án đều bị xóa bỏ. Người dùng có thể khôi phục lại hành động xóa Repo trong 90 ngày. Bước 1: Quay lại trang chính của Repo cần xóa, nhấp vào biểu tượng Settings Bước 2: Kéo đến mục Danger Zone, bấm nút xóa Repo ở mục cuối cùng Bước 3: Đọc bảng cảnh báo của Github, nhập chính xác tên Repo bạn muốn xóa Bước 4: Nhấn đồng ý lời khẳng định sẽ chịu trách nhiệm cho hành động này để xóa Repo Bước 5: Nhập mật khẩu để khẳng định lại lần nữa và xóa Repo thành công
  • 57. 46 Hình 36- Repo trên Github đã xóa 3.2 Cấu hình Git cơ bản Nhằm minh họa trực quan cách hoạt động của các lệnh Git cơ bản, nhóm đã thực hiện hai video quay lại quá trình sử dụng Git trên cả hai hệ điều hành. Các bước làm vẫn sẽ được trình bày đầy đủ bên dưới. - Link video trên Windows: https://youtu.be/4tJE4fUrL6U - Link video trên Linux: https://youtu.be/XVNO_Rml1Dk 3.2.1 Thiết lập ban đầu Điều đầu tiên cần làm sau khi cài đặt git là cấu hình chứng thực, thiết lập các tùy chọn ban đầu phù hợp với cá nhân người sử dụng. Những thông số cấu hình này nên chỉ làm một lần trên mỗi máy tính và nó sẽ không thay đổi kể cả người dùng có nâng cấp git. Họ có thể thay đổi các thông số cấu hình bằng cách sử dụng lại câu lệnh cấu hình. Git có một công cụ dòng lệnh là git config để cho người dùng tùy chỉnh các giá trị để git có giao diện và vận hành như họ muốn. Các giá trị có thể được chứa ở ba nơi khác nhau, muốn xác định người dùng cần gõ lệnh git config –list –show-origin, nó sẽ hiển thị file config được lưu trên đường dẫn nào, cũng như các giá trị đã được cấu hình mặc định bởi Git.
  • 58. 47 Hình 37- Xem thông số mặc định 3.2.1.1 Định danh Người dùng khai báo tên và địa chỉ mail trong file cấu hình Git. Điều này rất quan trọng vì Git sẽ dùng thông tin này trong lúc người dùng thực hiện lệnh commit (sẽ được nhắc đến sau). Họ chỉ cần 2 câu lệnh đơn giản như sau: Người dùng chỉ cần làm một lần động tác này với tùy chọn [--global], các đợt sau nếu muốn chuyển đổi cho một dự án nào đó, họ chỉ cần gõ lại lệnh này mà không cần tùy chọn trên. Nếu họ sử dụng công cụ có giao diện thì bản thân công cụ đó sẽ tạo sẵn cho người dùng 3.2.1.2 Kiểm tra cài đặt Git sẽ đọc một giá trị đến từ các file khác nhau, người dùng gõ lệnh git config – list để liệt kê các thiết lập mà Git tìm thấy.
  • 59. 48 Người dùng còn có thể kiểm tra những giá trị đặc trưng bằng lệnh git config <key> với tùy chọn “key” là thuộc tính như user, filter, core…. Hình 38- Xem xét tham số name thuộc User 3.2.1.3 Trợ giúp Hình 39- Website tập hợp các lệnh config Hình 40- Các lệnh config Git Người dùng có thể sử dụng các gợi ý trợ giúp được tích hợp sẵn trong công cụ là [--help] hoặc [-h], để sử dụng các lệnh [config] chỉnh sửa các thiết lập. Git sẽ hiển thị một trang web có các lệnh hướng dẫn cấu hình khi người dùng xài lệnh git help config.
  • 60. 49 Đôi lúc, người dùng chỉ cần trợ giúp ở một câu lệnh cụ thể, họ sẽ gõ git <tùy_chọn> -h với “h” chính là viết tắt của từ Help. Hình 41- Xem trợ giúp lệnh commit 3.2.2 Các lệnh cơ bản 3.2.2.1 Khởi tạo Git Repository ban đầu Mục đích tạo ra một thư mục lưu trữ trong Git để chứa những dữ liệu cần thiết của một dự án, mỗi thành viên, đặc biệt là người quản trị phải thực hiện những động tác sau: Bước 1: Tại Local, thành viên quản trị mở ứng dụng Git Bash cho Windows đi vào một đường dẫn để chứa dự án Hình 42- Tạo một thư mục chứa tập tin Bước 2: Tạo file dự án để thao tác
  • 61. 50 Hình 43- Tạo file dự án Bước 3: Người quản trị nhập nội dung cho file dự án Bước 4: Người quản trị nhập lệnh cấu hình file dự án - Sử dụng lệnh git init để khởi tạo một Repo tại đường dẫn đó - Gõ lệnh git status để xem tình trạng hiện tại của Repo, file index vẫn chưa vào vùng Staging - Gõ lệnh git add [file] thêm file index vào vùng Staging và kiểm tra lại trạng thái
  • 62. 51 - Để đưa file index ra khỏi vùng Staging, người quản trị gõ lệnh git rm –cached [file] - Sử dụng lệnh commit file để chụp lại trạng thái hiện tại, thêm thông điệp đính kèm (bắt buộc) để thông báo cho thành viên khác về mục đích Snapshot - Thêm đường dẫn HTTPs của Remote Repository mà người quản trị ban đầu, xài lệnh git push để đưa file lên server phục vụ cho mục đích làm việc từ xa cho các nhân viên
  • 63. 52 - Gõ lệnh git log để xem những hành động đã làm - Tải lại trang Web Github để kiểm tra file index trên Remote server 3.2.2.2 Cách Clone dự án bằng Git Khi đưa lên Remote Server, phía thành viên trong dự án sẽ clone dữ liệu về, rồi làm việc trong dữ liệu đó, làm theo yêu cầu cấp trên rồi đẩy dữ liệu đó lên lại Server. Có 2 cách để làm việc này, đó là sử dụng nút bấm trên Github hoặc sử dụng lệnh git clone của Git. - Trường hợp 1: Người dùng chọn tải trực diện về toàn bộ dự án trong định dạng file .zip thông qua giao thức HTTPs bằng cách nhấn mở xuống khung Code hoặc có thể bằng phần mềm Desktop của Github
  • 64. 53 Hình 44- Tải Github Repo bằng file zip - Trường hợp 2: Clone bằng câu lệnh Git được mô tả các bước như sau Bước 1: Người quản trị thêm các thành viên vào Repo trên Github Bước 2: Cấp quyền cho từng tài khoản quyền tương ứng Bước 3: Thành viên sử dụng lệnh git clone cùng với địa chỉ URL của Repo muốn lấy về trên Github rồi thực hiện.
  • 65. 54 Hình 45- Lấy về toàn bộ dự án Trong quá trình làm việc, thành viên muốn tương tác với nhóm và Server có thể xài các lệnh cơ bản như add, commit, push và pull. 3.3 Kết nối Git đến Github qua SSH 3.3.1 Khái niệm SSH SSH (Secure Shell) là một giao thức mạng dùng để thiết lập kết nối mạng một cách bảo mật. Khi làm việc với Git, SSH sẽ giúp ta trong 2 việc: - Bảo mật các kết nối của mình với server. - Không phải nhập mật khẩu mỗi lần push Code 3.3.2 Cơ chế làm việc SSH Người dùng sở hữu 2 Key (khóa): Public Key (khóa công khai) và Private Key (khóa bí mật). Public Key sẽ được lưu trữ trên Server của Git (Github là một ví dụ). SSH - agent đóng vai trò làm tất cả những việc còn lại cho bạn. Mỗi lần bạn push, SSH - agent sẽ tự gửi kèm theo các thông tin chứng thực, Github sẽ nhận diện ra bạn, và bạn không cần phải nhập mật khẩu nữa. Một điều lưu ý là Github quy định mỗi SSH Key chỉ được gắn với một tài khoản. 3.3.3 Các bước tạo khóa và kết nối Github Bước 1: Tạo khóa, mở cmd (Command Line) chạy với quyền quản trị hoặc mở Git Bash gõ câu lệnh ssh-keygen -t rsa -C “<tên email của bạn Github>”
  • 66. 55 Khi chạy câu lệnh,hệ thống sẽ hỏi bạn muốn lưu khóa ở đâu,mặc định sẽ lưu trong đường dẫn trên ../.ssh/id_rsa. Nếu đồng ý nhấn Enter. Tiếp theo đoạn mã tạo khóa sẽ mời nhập mật khẩu (Passpharse), nếu để trống nhấn Enter còn đặt mật khẩu, ta sẽ đặt mật khẩu của tài khoản Github Sau khi nhập mật khẩu xong sẽ ra kết quả như sau: Bạn có thể lưu giữ file ida_rsa (khóa bí mật) trong Keychain khi thêm nó vào SSH – agent. Khởi tạo SSH – agent bằng dòng lệnh eval $(ssh-agent –s) như trong hình. Hình 46- Thêm khóa bí mật vào SSH - agent Bước 2: Kiểm tra khóa Để mở file có chứa khóa vừa tạo, gõ câu lệnh cat ~/.ssh/id_rsa.pub với đuôi *.pub là định dạng của Public Key.
  • 67. 56 Hình 47- Nội dung khóa công khai Sao chép khóa vừa tạo như hình trên. Bước 3: Kết nối Vào Github.com chọn Setting sau đó chọn SSH and GPG keys. Sau đó chọn New SSH key Màn hình sẽ hiện ra bảng sau:
  • 68. 57 Phần Title là tiêu đề có thể đặt tùy thích. Phần Key là khóa vừa sao chép trong mục id_rsa.pub dán vào ô Key. Sau đó nhấn Add SSH key để thêm khóa vừa tạo. Bước 4: Kiểm tra Thử sao chép một Repo về máy Thiết lập kết nối Git với Github thông qua giao thức SSH, tạo chứng thực thông tin người dùng thành công
  • 69. 58 3.4 Cấu hình Git nâng cao Với các lệnh nâng cao của Git, nhóm em sẽ tập trung vào tìm hiểu tính năng nhánh trong Git, cách phân nhánh, gộp nhánh, đồng thời tìm ra các giải pháp khắc phục xung đột lúc phân nhánh hay thời khắc đẩy tập tin lên Repository. 3.4.1 Nhánh là gì, tại sao phải phân nhánh Nhánh trong Git cũng giống như một cái cây có thân chính là nhánh Master trong Git, từ nhánh chính này phát triển thành nhiều nhánh con, từ những nhánh con này đều phát triển “hoa”, “lá” và đều được gắn liền với nhánh chính. Các nhánh này đều có chung mục đích là làm cho cây của mục thêm phần sinh động và đẹp hơn. Git lúc đầu có nhánh gốc là nhánh Master. Câu chuyện được đặt ra là một thành viên muốn thêm một tính năng cho dự án có sẵn, nhưng phần chỉnh sửa lại dễ ảnh hưởng đến dự án chính. Branch ra đời. Tính năng một nhánh Master gốc thành nhiều bản sao của cùng một Repository, cho phép người dùng chuyển đổi qua lại giữa các trạng thái và phiên bản khác nhau. Từ những nhánh con đã phân tách, những người tham gia dự án có thể chỉnh sửa, thêm xóa chương trình của mình hợp lý, có thể kiểm tra quá trình hoạt động dự án ngay trên nhánh của mình mà không ảnh hưởng đến nhóm chính. Khi mọi sự hoàn tất người tham gia dự án có thể gộp nhánh của mình với nhánh chính cùng những tính năng mới để hoàn thiện dự án. Hình 48- Quy trình chia nhánh
  • 70. 59 3.4.2 Tạo nhánh Bước 1: Kiểm tra nhánh Chỉ có 1 nhánh Master (nhánh gốc) Bước 2: Phân nhánh Dùng lệnh git branch+<Tên nhánh> Bước 3: Kiểm tra nhánh đã tạo Như vậy nhánh b1 đã tạo thành công. 3.4.3 Phân nhánh Bước 1: Dùng lệnh git checkout +<tên nhánh chuyển> Bước 2: Kiểm tra nhánh người dùng đang truy cập Dùng lệnh git branch Dấu sao trước tên nhánh cho biêt vị trí nhánh hiện tại
  • 71. 60 3.4.4 Gộp nhánh Bước 1: Chuyển nhánh Chuyển sang nhánh b1 Bước 2: Tạo file text có tên “nhanh.txt” Tiến hành nhập thông tin file text sau khi nhấn enter tạo file text. Để lưu lại và thoát nhấn tổ hợp phím ctrl+D. Kết quả được hiển thị như hình dưới: Bước 3: Thêm file “nhanh.txt”vào nhánh b1 Bước 4: Ghi chú Bước 5: Kiểm tra Lệnh ls dùng kiểm tra file hiện có nhánh b1 Kiểm tra nhánh Master
  • 72. 61 Bước 6: Tiến hành gộp nhánh b1 vào nhánh Master Đầu tiên chuyển sang nhánh Master Tiến hành gộp nhánh b1 bằng lệnh git merge đối với b1 Tiếp theo kiểm tra các file nhánh Master Đã xuất hiện tên file “nhanh.txt” là file vừa tạo bên nhánh b1. 3.4.5 Xóa nhánh Bước 1: Chuyển sang nhánh Master Bước 2: Xóa nhánh b1 Dùng lệnh git branch -d +<tên nhánh xóa>
  • 73. 62 Bước 3: Kiểm tra Dùng lệnh git branch để xem nhánh hiện có Chỉ còn nhánh gốc là Master 3.5 Giải quyết xung đột trên Git Do cơ chế tự động tích hợp những gì thay đổi trong git, qua những thao tác push, pull, merge dòng lệnh không ít thì nhiều cũng phát sinh lỗi như trường hợp xung đột dòng lệnh, file dạng text “conflict” trên cấp độ file hoặc là nhánh. Xung đột chỉ ảnh hưởng đến nhà phát triển trong quá trình hợp nhất, những người còn lại không tham gia vào quá trình thay đổi file sẽ không biết gì về xung đột. Nguyên tác đưa ra là ai gây ra xung đột, người đó tự giải quyết. Nội dung mục này sẽ nói về các cách giải quyết xung đột theo hai trường hợp trong Git. 3.5.1 Xung đột tập tin trong một nhánh Để giải quyết xung đột tập tin, người quản trị cần làm những điều sau: Bước 1: Đưa file lên Remote Repo bằng lệnh git push Bước 2: Xem một file upload.txt có nội dung như sau
  • 74. 63 Bước 3: Một thành viên chỉnh sửa file ở dòng “First page” rồi lưu lại bằng nút “Commit Change” Bước 4: Một thành viên còn lại chỉnh sửa file ở phía Local mà không hay biết việc file đã bị chỉnh sửa trên server Bước 5: Thành viên này sử dụng các lệnh add, commit, push để đưa file lên Remote
  • 75. 64 Bước 6: Git thông báo lỗi tới người dùng, gợi ý sử dụng lệnh git pull để kéo dữ liệu về kiểm tra, Git sau đó sẽ hiện ra chi tiết lỗi cụ thể cho người dùng Bước 7: Thành viên tại Local xóa nội dung xung đột, giữ lại nội dung cần thiết cho dự án Bước 8: Sử dụng lại các lệnh đưa dữ liệu lên Remote server
  • 76. 65 Bước 9: Kiểm tra trên Github 3.5.2 Xung đột tập tin trong nhiều nhánh Trong một dự án bao gồm nhiều nhánh, mỗi nhân viên làm việc trên một nhánh. Khi xong phần công việc của mình, nhân viên gộp phụ của mình vào nhánh chính để hoàn thiện dự án. Tuy nhiên, trường hợp nhánh phụ có nhiều Commit kể từ thời điểm rẽ nhánh, khi gộp vào nó sẽ xem xét sự thay đổi trên các nhánh. Nhận thấy sự giống nhau về nội dung trên một dòng của từ 2 file trở lên, Git sẽ thông báo xung đột nhánh. Để giải quyết tình trạng này, nhóm em mô phỏng lại quá trình gộp nhánh trên 2 nhánh có sẵn là Master và Alpha, xảy ra xung đột qua các bước sau: Bước 1: Kiểm tra hai nhánh hiện có
  • 77. 66 Cả 2 nhánh đều có nhiều Commit kể từ thời điểm rẽ nhánh Khi gộp Git sẽ xem xét trên 3 thời điểm, thời điểm commit cuối của các nhánh và thời điểm rẽ nhánh, đó lần lượt là commit với các Snapshot C2, C4, C7 (các Commit này được nhóm làm từ trước). Hình 49- Rẽ nhánh tại Snapshot C2 Bước 2: Trở về thời điểm Snapshot C2 (có mã Hash là 1b136f7), thời điểm rẽ nhánh từ Master ra Alpha bằng lệnh git checkout tạo ra một nhánh tạm để HEAD trỏ vào C2
  • 78. 67 Bước 3: Mở thư mục làm việc sẽ thấy có 3 file với nội dung trống bên trong Bước 4: Kiểm tra nhánh Alpha với Commit cuối ở Snapshot C4 Trong thư mục làm có 4 file, chỉ duy nhất file 1.txt có nội dung Bước 5: Kiểm tra nhánh Master tại Commit cuối ở C7 Trong thư mục lúc này có duy nhất file 4.txt có nội dung rỗng, các file còn lại đều có nội dung. Điểm đặc biệt cần lưu ý ở file 1.txt có một nội dung khác với nội dung chính nó ở nhánh Alpha Nguyên nhân gây xung đột chính là nội dung của file 1.txt nếu gộp nhánh Alpha vào Master, Git không biết chọn giữ lại bản nội dung nào của file 1.txt. Bước 6: Gộp nhánh Alpha vào Master để thấy rõ sự xung đột
  • 79. 68 Git vẫn đang trong quá trình Merge nhưng chờ xử lý xung đột của file 1.txt. Git không tạo Commit mới cho tới khi nào hết xung đột. Kiểm tra lại trạng thái, ta thấy được 3.txt đã có sẵn trong vùng Stag nhưng file 1.txt lại chưa được gộp. Bước 7: Xử lý xung đột thủ công bằng cách mở file xung đột (ở đây là 1.txt) và xóa nội dung ta cần xóa Hình 50- Hai nội dung xung đột gộp nhánh Nội dung nằm giữa <<<<<<< HEAD và ======= là nội dung từ Master, từ ======= và >>>>>>> alpha là nội dung từ Alpha. Chọn phần nội dung cần xóa là của Alpha, Sau khi hết xung đột, Git tự động gộp xong nhánh. Hình 51- Giữ lại nội dung của Master
  • 80. 69 Bước 8: Tiến hành đưa file vào vùng Stage và tạo ra Commit cùng thông điệp “C8” để hoàn thành việc gộp nhánh Bước 9: Xem lịch sử Commit của cả hai nhánh bằng lệnh git log Hình 52- Lịch sử Commit trên Alpha Hình 53- Lịch sử Commit trên Master Biểu diễn các lịch sử Snapshot theo hình sau khi gộp nhánh Để giải quyết xung đột trong Git, cách đơn giản là chỉnh sửa nội dung trên file dẫn tới xung đột, sau đó cho nó vào Stag và chỉnh sửa trong đó. Một số gợi ý được đưa ra
  • 81. 70 để giảm thiểu sự xung đột, đặt biệt là trong một dự án có quá nhiều thành viên cùng thực hiện chỉnh sửa file. - Xác định một quy trình làm việc ngay từ đầu cho các thành viên trong một dự án - Cam kết thường xuyên đẩy những tập lệnh nhỏ, nếu có xung đột sẽ dễ giải quyết hơn việc một lượng lớn các tập lệnh được đẩy đến kho lưu trữ từ xa (Remote Repo) của Git - Nên kéo (pull) các thay đổi từ kho lưu trữ từ xa Git trước khi làm việc trên các tập lệnh mới và trước khi commit - Mỗi thành viên nên làm việc trên từng tính năng trên các nhánh riêng biệt tại cùng một thời điểm 3.6 Cài đặt, cấu hình Git LFS 3.6.1 Cài đặt Git LFS Người dùng có nhu cầu sử dụng công cụ Git LFS để quản lý Repository có các file dung lượng lớn hoạt động trơn tru có thể tham khảo ở trang chủ qua đường dẫn https://git-lfs.github.com/ và tải về phiên bản công cụ LFS phù hợp cho hệ điều hành đang sử dụng. Hình 54- Trang chủ tải Git LFS cho Windows Việc cài đặt sẽ trải qua 2 bước đơn giản như sau:
  • 82. 71 Bước 1: Tới đường dẫn chứa file cài vừa tải nhấn chuột hai lần để Windows để thiết lập bảng cài đặt Git LFS Bước 2: Mở Git Bash, gõ lệnh git lfs install và xác nhận Git LFS cài thành công *Công cụ Git LFS được cài đặt sẵn trong Git Bash nên các bước trên sẽ mô phỏng quy trình cài đặt cho trường hợp không tìm thấy LFS khi cần sử dụng công cụ. 3.6.2 Cấu hình Git LFS Giả sử người dùng có một Repo đã liên kết với Remote Repo trên Github, với 2 câu lệnh dưới cho thấy file .git Repo có dung lượng rất nhẹ với 77 Kbyte. Yêu cầu đối với Repo này là phải bao gồm thêm các file dung lượng lớn để phù hợp với kế hoạch của dự án, trải qua các bước sau: Bước 1: Thêm 3 file có dung lượng khá lớn lần lượt từ 1 mb, 10mb đến 100 mb, đẩy nó lên Repository Origin của Github để khám phá công cụ LFS Bước 2: Kiểm tra lại bằng lệnh git status thấy được một file ở dạng Untracked chính là file chứa 3 file dung lượng lớn
  • 83. 72 Bước 3: Khởi tạo Repo để cài đặt Git LFS, áp dụng các thiết lập của LFS vào Repo hiện hành, gõ lệnh git lfs install Bước 4: Cho LFS biết loại định dạng file người dùng cần theo dõi trong dự án, file ví dụ có đuôi là *.file, nó sẽ thông báo người dùng file đang được theo dõi Câu lệnh này sửa đổi file .gitattributes của kho lưu trữ Repo và liên kết các tệp lớn với Git LFS Bước 5: Thêm nội dung của đường dẫn vào Repo Bước 6: Bật trạng thái xem dữ liệu đã được thêm vào Repo Ta có thể xem tổng dung lượng lúc này của file .git Repo đã tăng lên đáng kể
  • 84. 73 Tất cả các file được đặt dưới một đường dẫn thư mục mới tên lfs. Đường dẫn này sẽ không đồng hành cùng Repo trong việc xài lệnh add, checkout Bước 7: Thêm file .gitattributes vào Index để nó song hành cùng Repo Bước 8: Thực hiện commit file lớn này Chỉnh sửa thông điệp cho Commit này Bước 9: Tạo một nhánh riêng để quản lý rồi đẩy lên Github Remote Origin
  • 85. 74 Bước 10: Push nhánh này với nội dung các file lớn tới Remote Repo, tùy vào tốc độ mạng, nhánh sẽ push nhanh hơn Nhánh đã xuất hiện ở Remote Origin để mọi người có thể kéo dữ liệu về sử dụng Việc lấy dữ liệu về lúc này khá dễ dàng vì dữ liệu được lấy về là dữ liệu cần thiết chứ không phải toàn bộ phiên bản như trước khi xài Git LFS. Điều này được minh họa qua các bước sau. Bước 1: Xài lệnh git clone để lấy lại dữ liệu file lớn và bỏ vào một đường dẫn khác Bước 2: Xem tổng dung lượng của file .git
  • 86. 75 Khi sử dụng lệnh Clone thì nhánh mặc định của ta là nhánh Master, kiểm tra trạng thái để thấy nhánh chứa file dung lượng lớn Bước 3: Xài lệnh checkout để chuyển sang nhánh quản lý file dung lượng lớn và xem chuyện gì xảy ra Git Hooks (tính năng can thiệp vào thông số của Git bằng những đoạn lệnh ngẫu nhiên) cho lệnh Checkout bắt lấy các file dữ liệu lớn và ta có thể kiểm tra lại dung lượng file .git lúc này đã tăng lên. Tất cả dữ liệu tải về được bỏ vào đường dẫn file lfs Một điều tuyệt vời nữa là người dùng có thể chuyển nhánh thoải mái, Git LFS sẽ không thêm bất cứ file nào ảnh hưởng đến nhánh khác
  • 87. 76 Git LFS chỉ lưu trữ (cached) các file lớn được cho phép theo dõi trong thư mục đường dẫn lfs và lấy lại file đó. 3.7 Tích hợp với hệ thống SVN Một doanh nghiệp làm việc luôn triển khai một hệ thống nhanh chóng, rồi duy trì hệ thống đó đảm bảo sự ổn định cho công việc. Đó là nguyên nhân việc chuyển giao hệ thống luôn là vấn đề nan giải. Một doanh nghiệp có một dự án trên VCS không thể chuyển sang Git ngay lập tức, họ sẽ phải sử dụng nhiều cách để thực hiện điều đó. Git có những tính năng tuyệt vời, đóng vai trò làm client, hỗ trợ cho việc chuyển giao giữa các VCS như Subversion, Perforce, Bazaar, TFS…. Một trong những tính năng đó được gọi là cầu “bridge” thông qua các dữ án sử dụng VCS khác. Do mục đích yêu cầu đề tài, nhóm sẽ chỉ tập trung vào cách triển khai chuyển đổi kho code từ SVN sang git. 3.7.1 Giới thiệu SVN2Git SVN là một cái tên điển hình trong mô hình CVCS, nó đã trụ vững suốt một thập kỉ. Một phần lớn các dự án phát triển mã nguồn mở và một số lượng lớn các dự án doanh nghiệp sử dụng Subversion để quản lý mã nguồn của họ. Muốn chuyển đổi kho dữ liệu từ SVN sang Git một cách bán phần, git sử dụng tính năng cầu hai chiều “bidirectional bridge” gọi là Git SVN. Công cụ này mang lại nhiều sự tiện lợi cho cả hai bên. - Cho phép người dùng sử dụng git như là một client hợp pháp đối với Subversion server - Hỗ trợ các tính năng tại local của git, sau đó có thể push dữ liệu đó lên Subversion server - Có thể chia, gộp nhánh, sử dụng khu vực staging, dùng rebase - Một cách gián tiếp giúp các lập trình viên làm việc hiệu quả trong lúc chủ doanh nghiệp tìm kiếm giải pháp chuyển đổi hoàn toàn sang git
  • 88. 77 Git ở đây sẽ đóng vai trò như client đối với server Subversion, thay thế các Subversion client khác nhau TortoiseSVN hay công cụ tích hợp trong Eclipse. Hình 55- Mô hình sử dụng Subversion clients Việc ra mắt công cụ này được xem là một liều thuốc mở rộng đối với mô hình DVCS vốn đang bị hạn chế. 3.7.2 Cấu hình Git – SVN Điều đầu tiên người dùng cần là một SVN repository thông thường và họ có quyền write lên nó nên họ cần cài đặt SVN. Do để thỏa yêu cầu đề tài nên toàn bộ quá trình cài đặt SVN sẽ được tóm gọn thông qua các trang web hướng dẫn sau: - Cài đặt trên Linux: https://www.linuxcloudvps.com/blog/how-to-install-svn- server-on-debian-9/ - Cài đặt trên Windows (VisualSVN): https://o7planning.org/vi/10207/huong- dan-cai-dat-va-quan-ly-visual-svn-server VisualSVN là một sản phẩm của Microsoft sử dụng như một Repository server, có bản trả phí và miễn phí, lưu trữ các file chia sẻ giữa các thành viên trong nhóm. Các thành viên sẽ cài đặt chương trình Subversion miễn phí để giao tiếp với server. Thiết lập chuyển kho code, người dùng cần tạo một SVN Repo có phân quyền. Muốn làm được điều đó, trước tiên, họ phải dựng được một server có cài sẵn Subversion. Do SVN yêu cầu mỗi người dùng phải có một tài khoản để ghi lại các thông tin commit nên cần ánh xạ Subversion client thành “chủ nhân” Git. Server của SVN có thể dùng VisualSVN server để cài đặt mô phỏng trên Windows. Bước 1: Cài đặt VisualSVN server để tương tác với các clients
  • 89. 78 Hình 56- Giao diện VisualSVN Server Bước 2: Client SVN dùng Totoise SVN để tích hợp Git vào sử dụng Hình 57- Giao diện TortoiseSVN Bước 3: Tiến hành chuyển đổi SVN sang Git. Từ SVN Server tiến hành xuất repository về máy tính và lưu trữ trong thư mục của Git đang làm việc Hình trên đang có 2 file .txt trong repo có tên test cần chuyển đổi. Bước 4: Tiếp theo nhấn chuột phải Repo tên test -> all task -> export repo
  • 90. 79 Bước 5: Tùy vào các lựa chọn phù hợp nhu cầu, người dùng nhấn next Phía trên là chọn thư mục muốn lưu sau khi xuất repo của SVN và phía dưới là tên repo khi xuất. Cuối cùng Repo được xuất thành công.
  • 91. 80 Bước 6: Tiến hành vào thư mục đã trỏ tới khi xuất Repo SVN để xem kết quả Bước 7: Hình trên đã thấy Repo SVN xuất thành công. Tiếp đến tiến hành đưa Repo SVN đã xuất lên Github quản lý. Đầu tiên kéo thư mục từ kho Github xuống để đồng bộ với thư mục Local
  • 92. 81 Bước 8: Sử dụng câu lệnh đẩy lên Repo Master như thông thường đối với Git Bước 9: Lúc này ta truy cập trình duyệt vào trang Github theo kho quản lý code của nhóm, kiểm tra lại file đã được đưa lên thành công.
  • 93. 82 Thư mục SVN đã xuất hiện trên Repo tại Github. Việc chuyển đổi kho code từ SVN Server sang Git và đưa lên kho quản lý Github thành công.
  • 94. 83 CHƯƠNG 4: KẾT LUẬN Trong thời đại phát triển vượt bậc hiện nay, nhu cầu về thông tin ngày càng tăng trong mọi hoạt động nói chung và trao đổi thông tin nói riêng, thì nhu cầu trao đổi thông tin rất cần thiết để đẩy mạnh việc tạo ra những sản phẩm ngày càng có giá trị. Tin học hóa trong quản lý, quá trình áp dụng các thành tựu khoa học công nghệ thông tin vào các hoạt động quản lý. Quá trình này nhằm mục đích nhằm cắt giảm bớt thời gian, giải quyết công việc với tốc độc cao và độ chính xác cao. Việc áp dụng Git vào việc quản lý kho dữ liệu cho một dự án nào đó vô cùng quan trọng và cần thiết cả với những dự án lớn nhỏ nhất, với những dự án có nhiều thành viên tham gia xây dựng. Bài báo cáo này mang đến người đọc thấy rõ lợi ích mang lại từ Git. Nhờ có Git giúp đơn giản hóa công việc quản lý “công sức” đóng góp từ thành viên tham gia dự án. Git góp phần làm giảm sự đụng độ, hay sự bất cẩn một thành viên trong dự án vô tình làm hỏng cả một phần mềm gây ảnh hưởng tới khách hàng và công ty, điều này là thiệt hại lớn đối với doanh nghiệp điều mà không ai mong muốn. Đánh giá đề tài Những công việc đã làm được - Đánh giá tổng quan, tìm hiểu Git/Github - Cài đặt môi trường và triển khai Git Bash - Thao tác cấu hình các lệnh cơ bản (clone, init, push, …) - Thao tác cấu hình một số lệnh nâng cao (merge, branch, conflict, …) - So sánh Git với SVN - Triển khai chuyển đổi từ kho dữ liệu từ SVN sang Git Những công việc chưa làm được - Triển khai việc trộn kho code để thực hiện quản lý trên website - Nêu ra tính năng Workflow của Git - Triển khai LFS chưa có đủ dữ liệu lớn để thao tác kiểm thử. Hướng phát triển của đề tài
  • 95. 84 Git Flow là tên gọi của 1 công cụ (Command) hỗ trợ Branch Model do Vincent Driessen đề xuất ra, trong git-flow có 5 kiểu với mỗi vai trò khác nhau (tùy trường hợp là 6 kiểu) như Master Branch, Develop Branch, Release Branch, Hotfix Branch, Support Branch. Chuyển đổi các kiểu với nhau để phát triển bằng việc thiết lập trước các nhánh, những tập luật khi merge, dù có bao nhiêu lập trình viên cùng thời điểm phát triển vẫn có thể quản lý Branch dễ dàng, và tránh được những vấn đề do gộp nhánh. Git Flow đưa ra các quy ước để triển khai công việc. Nó được tổng kết qua quá trình làm việc thực tiễn của nhiều nhóm trên thế giới hiện nay và mang lại kết quả khả quan đáng kinh ngạc. Mục đích là các nhóm công việc triển khai song song nhưng không ảnh hưởng tới nhau. Các môi trường phát triển, Staging và Production tách biệt giúp quá trình kiểm thử (QA), trả lời phản hồi và xử lý các vấn đề được gọn gàng và thống nhất hơn. Ý tưởng là duy trì các nhánh Branch không đổi - không xoá (tính cố định) trong suốt dòng đời sản phẩm. Branch Master sẽ luôn là Branch chính áp dụng cho Production, trong khi các Branch Hotfix, Features hay Develop cung cấp các phiên bản để phục vụ QA và hoàn thiện trước khi được đẩy lên Master. Khác với cách thông thường tạo ra nhiều vấn đề xảy ra ngay trên Production, thứ mà chúng ta hay gọi là “rút kinh nghiệm từ những sai lầm thực tiễn”, Git Flow đẩy quá trình QA vào một phần bắt buộc cho cả lập trình viên, nhóm QA và yêu cầu sự hoàn thiện cao hơn về chất lượng đầu ra.
  • 96. 85 TÀI LIỆU THAM KHẢO Tài liệu [1] Zack Rusin, Git cheat sheet, Based on the work of: Sebastien Pierre Xprima Corp, 2007 [2] Scott Chacon, Ben Straub, Pro Git 2nd Edition, Apress, 2014 Website [3] https://backlog.com/git-tutorial/vn/reference/ [4] https://git-scm.com/doc [5] https://thachpham.com/series/git-co-ban [6] https://linuxacademy.com/blog/linux/git-terms-explained/ [7] https://laptrinhx.com/top-10-version-control-systems-87231571/ [8] https://xuanthulab.net/git-va-github/ [9] https://www.atlassian.com/git [10] https://www.linuxcloudvps.com/blog/how-to-install-svn-server-on-debian-9/ [11] https://kenhgiaiphap.com/news/github-la-gi-cach-su-dung-github-chi-tiet- 2ubc9q9 [12] https://lptech.asia/kien-thuc/git-la-gi-su-dung-git-nang-cao-chuan-git-flow