Làm Việc Với Nhánh (branches) - - VnPro

Hãy nhớ rằng git lưu giữ lịch sử hoạt động của mọi commit đã thực hiện. Lịch sử này (được gọi là snapshot theo thuật ngữ git) nêu chi tiết tất cả các thay đổi đối với phần mềm theo thời gian và đảm bảo tính toàn vẹn của bản ghi này bằng cách áp dụng hàm băm SHA-1. Hàm băm này là một chuỗi 40 ký tự được gắn với mỗi và mọi commit. Ví dụ 2-5 cho thấy một ví dụ về ba commit với một băm, được hiển thị bằng lệnh git log

Ví dụ 2-5 Kết quả của lệnh git log

Lưu ý rằng mục đầu tiên là trạng thái của commit hiện tại, còn được gọi là HEAD. Các mục khác hiển thị lịch sử thứ tự thời gian của các commit. Hình 2-11 cho thấy một cái nhìn trực quan của lịch sử commit ba bước đơn giản này; để dễ nhìn, chỉ có bốn giá trị đầu tiên của hàm băm được sử dụng.

Hình 2-11 Lịch sử commit của git

Để thêm một nhánh mới, bạn chỉ cần sử dụng lệnh git branch và cung cấp tên cho nhánh mới, sử dụng cú pháp sau:

Bạn có thể tách nhánh từ một commit cụ thể nào nó trong lịch sử, để làm điều này ta chỉ định một commit bằng cách nhập mã băm của commit đó từ lịch sử commit. Theo mặc định, git chọn commit mới nhất để tách nhánh (HEAD). Ngoài ra, bạn có thể xóa một nhánh khi bạn không còn cần nó nữa bằng cách sử dụng cờ -d.

Ví dụ sau đây cho thấy cách tạo một branch và hiển thị các branch hiện tại bằng lệnh git branch không có đối số:

Dấu * bên cạnh master cho thấy rằng branch bạn đang ở vẫn là branch chính, nhưng bây giờ bạn có một branch mới có tên là tính năng mới. Git chỉ đơn giản là tạo một con trỏ đến commit mới nhất và sử dụng commit đó làm phần khởi đầu cho nhánh mới. Hình 2-12 mô tả trực quan sự thay đổi này.

Hình 2-12 Thêm một branch

Để chuyển đến branch mới và thay đổi thư mục làm việc, bạn phải sử dụng lệnh git checkout, có cú pháp sau:

Tham số -b rất hữu ích khi bạn muốn để kết hợp lệnh git branch với git checkout để tạo nhánh mới và chuyển thẳng đến nhánh đó cùng một lúc, tiết kiệm một chút thao tác nhập. Ví dụ này di chuyển HEAD trên máy cục bộ của bạn sang nhánh mới, như hình 2-13:

Hình 2-13 Thay đổi HEAD thành một nhánh mới

Bây giờ bạn đang có một vùng làm việc riêng biệt, nơi bạn có thể xây dựng tính năng của mình. Tại thời điểm này, bạn sẽ muốn thực hiện git push để đồng bộ hóa các thay đổi của mình với kho lưu trữ từ xa.

Khi công việc của bạn đã hoàn thành trên nhánh riêng, bạn có thể hợp nhất nó trở lại nhánh code chính và sau đó xóa nhánh bằng cách sử dụng lệnh git branch -d (tên nhánh).

Hợp nhất các nhánh (merge)

Quá trình hợp nhất trong git được sử dụng để xử lý việc kết hợp nhiều nhánh thành một. Lệnh git merge được sử dụng để giúp người dùng làm điều này dễ dàng hơn và cung cấp một cách đơn giản để quản lý các thay đổi. Nó có cú pháp sau:

Để hiểu quá trình hợp nhất, hãy xem 2 branch của bạn. Hình 12-14 cho thấy tất cả các commit đã diễn ra như một phần của việc xây dựng tính năng. Ngoài ra, bạn có thể xem các commit khác cũng đã xảy ra trên branch chính.

Hình 2-14 Hai nhánh với commits

Để hợp nhất được hai nhánh, git phải so sánh tất cả những thay đổi đã xảy ra trong hai nhánh này. Ví dụ bạn đang có một tệp văn bản tồn tại trong cả nhánh master và nhánh newfeature, và vì mục đích đơn giản, chỉ có một vài dòng văn bản. Hình 12-15 hiển thị tệp văn bản branch chính.

Hình 2-15 Tệp văn bản trong nhánh master

Trong nhánh newfeature, tệp văn bản này đã được sửa đổi với một vài dòng code cho chức năng mới.

Hình 12-16 cho thấy một thay đổi đơn giản được thực hiện đối với tệp văn bản.

Hình 2-16 Các thay đổi đối với tệp văn bản trong nhánh newfeature

Trên nhánh newfeature, bạn có thể thực hiện các lệnh sau để thêm các thay đổi vào index và sau đó thực hiện thay đổi:

Giờ đây, nhánh này đã được đồng bộ hóa với những thay đổi mới và bạn có thể chuyển trở lại branch chính bằng lệnh sau:

Từ nhánh master, sau đó bạn có thể thực thi lệnh git merge và xác định branch để hợp nhất (trong trường hợp này là nhánh newfeature):

Trong ví dụ đơn giản này, không có thay đổi nào được thực hiện đối với nhánh master và git có thể tự động hợp nhất hai nhánh bằng cách tạo một commit kết hợp mới có nội dung mới từ nhánh newfeature. Lưu ý rằng kết quả ở trên có dòng chữ "fast-forward"; điều này đề cập đến việc bỏ qua từng cập nhật trong quá khứ của branch, giống như tua nhanh qua các phần nhàm chán của một bộ phim. Tại thời điểm này, bạn có thể xóa nhánh newfeature vì code trong đó đã được chuyển sang nhánh master. Hình 2-17 minh họa cách git thực hiện việc này: git tạo một commit mới có hai source.

Hình 2-17 git merge giữa 2 branch

Xử lí xung đột (Conflicts)

Hợp nhất các nhánh là một tính năng rất hữu ích, nhưng điều gì sẽ xảy ra nếu cùng một tệp được chỉnh sửa bởi hai developer khác nhau? Bạn có thể có xung đột về việc thay đổi nào được ưu tiên hơn. Git cố gắng xử lý việc hợp nhất một cách tự động, nhưng khi có xung đột, git phụ thuộc vào sự can thiệp của con người để quyết định những gì cần giữ lại. Trong ví dụ trước, nếu có những thay đổi được thực hiện đối với text1 trong cả nhánh master và nhánh newfeature, bạn sẽ thấy thông báo sau sau khi sử dụng lệnh git merge:

Ngoài ra, file text1 sẽ trông như trong hình 2-18 (cho thấy sự hợp nhất xung đột).

Hình 2-18 hợp nhất xung đột git

Git cho bạn thấy rằng “line 3” đã được thêm vào file text1 trên branch chính và “new feature code” đã được thêm vào file text1 trên nhánh newfeature. Git cho phép bạn xóa một hoặc giữ cả hai. Bạn chỉ cần chỉnh sửa tệp, loại bỏ các phần mà git đã thêm vào để làm nổi bật sự khác biệt và lưu tệp. Sau đó, bạn có thể sử dụng git add để thêm các thay đổi của mình vào index và và git commit để lưu thay đổi vào kho lưu trữ cục bộ, như trong ví dụ sau:

So sánh các commits với nhau bằng diff

Lệnh diff là một trong những git tool mạnh mẽ nhất. Nó cho phép bạn so sánh các tệp và văn bản để xem bạn muốn sử dụng cái nào nếu có nhiều tùy chọn. Khả năng so sánh các commit cụ thể trong git giúp bạn dễ dàng biết những gì nên giữ và những gì cần loại bỏ giữa hai phiên bản code tương tự.

Lệnh diff nhận dạng hai tập hợp đầu vào và đầu ra dựa vào sự khác biệt hoặc thay đổi giữa chúng. Đây là cú pháp của nó:

Git diff xem xét lịch sử các commit của bạn, các tệp riêng lẻ, các branch và các tài nguyên git khác. Đó là một công cụ rất hữu ích để khắc phục sự cố cũng như so sánh code giữa các commit. Nó là một dòng lệnh với rất nhiều tùy chọn và tham số, điều này làm cho nó giống một con dao xếp đa năng Thụy Sỹ về mặt chức năng. Một trong những chức năng hữu ích nhất của diff là có thể thấy sự khác biệt giữa ba cấu trúc cây git. Sau đây là các biến thể của lệnh git diff mà bạn có thể sử dụng:

git diff: lệnh này làm nổi bật sự khác biệt giữa thư mục làm việc của bạn và index (nghĩa là, những gì chưa được thêm vào index)

git diff --cached: lệnh này hiển thị bất kỳ thay đổi nào giữa index và lần commit cuối cùng của bạn.

git diff head: lệnh này hiển thị sự khác biệt giữa commit gần đây nhất của bạn và thư mục làm việc hiện tại của bạn. Nó rất hữu ích để xem điều gì sẽ xảy ra với lần commit tiếp theo của bạn.

Sau đây là một ví dụ về việc thực thi git diff --cached sau khi text2 được thêm vào index:

Git diff đã nhận biết việc có sự bổ sung tệp mới và hiển thị kết quả so sánh trên 2 file a/b. Vì đây là một tệp mới nên không có gì để so sánh với nó, bạn sẽ thấy --- /dev/null trong kết quả so sánh của bên a. Ở bên b, bạn thấy +++ b/text2, hiển thị việc bổ sung tệp mới, theo sau là danh sách những gì khác nhau. Vì file này không tồn tại trước đó nên bạn thấy -0,0 và +1. Dòng cuối cùng hiển thị đoạn text đã được thêm vào tệp mới. Đây là một ví dụ rất đơn giản với một dòng code. Trong một tệp lớn, bạn có thể thấy một lượng lớn text.

Một chức năng rất hữu ích khác của git diff là so sánh các nhánh. Bằng cách sử dụng git diff (tên nhánh), bạn có thể xác định sự khác biệt giữa các tệp trong nhánh bạn hiện đang ở và tệp ở nhánh mà bạn đã cung cấp tên trong đối số. Phần sau so sánh file text1 giữa nhánh master và nhánh newfeature, bạn có thể thấy “line 3” hiện trên tệp text1 của nhánh newfeature

Phần này đã trình bày khá nhiều cú pháp và câu lệnh mà bạn sẽ thường xuyên thấy khi làm việc với git. Bạn cần phải dành thời gian làm việc với các lệnh này trên máy tính của bạn và làm quen với chúng để bạn sẽ sẵn sàng cho kỳ thi 200-901 Devnet Associate DEVASC. Đảm bảo rằng bạn đang sử dụng các tài liệu như Git documentation để tìm hiểu về bất kỳ lệnh nào bạn chưa hiểu hoặc muốn hiểu sâu hơn. Tất cả các lệnh này đều có rất nhiều độ sâu để bạn khám phá.

Review code

Mọi tác giả giỏi đều cần một biên tập viên. Cuốn sách này thậm chí sẽ không thể làm người đọc hiểu được một nửa nếu trong thực tế chúng tôi không nhờ người khác kiểm tra công việc của chúng tôi để đảm bảo độ dễ hiểu và độ chính xác kỹ thuật. Tại sao code bạn viết phải được đối xử khác biệt? Mục đích đằng sau quá trình review code là để lấy những đoạn code tốt và làm cho nó tốt hơn bằng để người khác xem và nhờ họ nhận xét, qua đó tìm kiếm các lỗi tiềm ẩn. Khi bạn phát triển phần mềm, phần lớn thời gian của bạn là dành cho chính bạn - chỉ bạn và bàn phím. Đôi khi bạn sẽ bị sót lỗi hoặc sử dụng những thuật toán không hiệu quả, một đợt review code đơn giản có thể nhanh chóng phát hiện ra các vấn đề này.

Ngoài các khía cạnh đã đề cập ở trên, tại sao bạn nên tiến hành review code? Sau đây là một số lợi ích chung của việc review code:

• Nó giúp bạn tạo phần mềm chất lượng cao hơn.
• Nó cho phép nhóm của bạn gắn kết hơn và cung cấp các dự án phần mềm đúng hạn.
• Nó có thể giúp bạn tìm ra nhiều lỗi và những đoạn mã không hiệu quả, khi mà các kỹ thuật như unit tests và functional tests có thể bỏ sót, giúp phần mềm của bạn đáng tin cậy hơn.

Có nhiều cách để tiến hành code review. Một số tổ chức sử dụng các ứng dụng chuyên biệt như Gerrit, vài tổ chức khác lại tiến hành đánh giá như thể họ là giáo sư chấm điểm bài báo cáo đại học. Dù bạn sử dụng quy trình nào, sau đây là một số phương pháp hay để giúp việc xem xét mã của bạn hiệu quả:

• Sử dụng một checklist (danh sách kiểm tra) cho việc review code, bao gồm các quy tắc cụ thể của tổ chức (quy ước đặt tên, bảo mật, cấu trúc lớp, v.v.) Và bất kỳ khía cạnh nào cần xem xét đặc biệt. Mục đích là để có một quy trình có thể lặp lại để mọi người tuân theo.
• Xem lại code, không phải xem người đã viết nó. Tránh trở nên rô bốt và khắc nghiệt để không làm tổn thương cảm giác của mọi người và làm họ nản lòng. Mục tiêu là code tốt hơn, không phải là nhân viên bất mãn.
• Hãy nhớ rằng review code là một món quà. Không ai chê con của bạn là xấu xí cả. Bỏ tự ái qua một bên và lắng nghe, phản hồi bạn nhận được sẽ khiến bạn trở thành lập trình viên tốt hơn về lâu dài.
• Đảm bảo các thay đổi đã được đề xuất phải được commit lại vào mã nguồn ban đầu. Bạn cũng nên chia sẻ những phát hiện của bạn với tổ chức để mọi người có thể học hỏi từ những sai lầm và cải thiện kỹ năng của họ.

Nhiệm vụ chuẩn bị bài thi

Như đã đề cập trong phần “cách sử dụng cuốn sách này” trong phần giới thiệu, bạn có một số lựa chọn để ôn thi: các bài tập ở đây, chương 19, “Chuẩn bị cuối cùng” và các câu hỏi mô phỏng kỳ thi trên trang web đồng hành .

Xem lại tất cả các chủ đề chính

Xem lại các chủ đề quan trọng nhất trong chương này, được ghi chú bằng biểu tượng chủ đề chính ở lề ngoài của trang. Bảng 2-2 liệt kê các chủ đề chính này và số trang của mỗi chủ đề được tìm thấy.

Bảng 2-2 các chủ đề chính

Key topic Element	Description	Page Number
Paragraph	Waterfall	27
Paragraph	Lean	28
Paragraph	Agile	29
Paragraph	Model-view-controller (mvc) Pattern	30
Section	Observer pattern	31
Paragraph	Getting to know bash	32
Paragraph	Software version control	38
Section	Using git	42
Section	Conducting code review	55

Quy ước các thuật ngữ chính trong chương này và kiểm tra câu trả lời của bạn trong bảng glossary:

Software development lifecycle (sdlc)

Waterfall

Lean

Agile

Model-view-controller (mvc)

Observer

Software version control

Git

Github

Repository

Staging

Index

Local workspace

Thông tin khác

• » TỔNG QUAN VỀ CHỨNG CHỈ NGHỀ NGHIỆP CISCO (19.11.2020)
• » Chứng chỉ DEVNET của cisco (19.11.2020)
• » TỔNG QUAN VỀ CISCO DEVNET (19.11.2020)
• » Bạn có biết? (19.11.2020)
• » Waterfall (19.11.2020)
• » Các mô hình thiết kế thông dụng (19.11.2020)
• » Cách sử dụng Linux Bash (19.11.2020)
• » SOFTWARE VERSION CONTROL (19.11.2020)