Trong Phần 2, chúng ta đã nói về các nhánh và cách sử dụng chúng. Điều gì xảy ra khi bạn có nhiều thay đổi và bạn muốn hợp nhất chúng thành mã chính? Về cơ bản, nó phụ thuộc vào tình trạng hiện tại của kho lưu trữ là gì?
Vì vậy, ở đây, bạn có thể thấy rằng có nhiều commit. Nhánh chính ở giai đoạn C1 trong khi nhánh đặc trưng ở xa hơn thế. Và trong thời gian này, vì không có thay đổi nào đối với nhánh chính, những gì Git có thể làm về cơ bản là di chuyển con trỏ nhánh. Nhưng trước khi di chuyển con trỏ nhánh, nó cũng tích hợp những thay đổi đó.
Tất nhiên, trong môi trường đa nhà phát triển thông thường, điều này hiếm khi xảy ra vì bạn không thể chỉ đơn giản là nói với các nhà phát triển, vui lòng ngừng commit công việc của bạn và đợi tôi hợp nhất nó. Vì vậy, những gì bạn thường làm là một cái gì đó phức tạp hơn một chút. Nhưng đây vẫn là cách dễ dàng để sửa chữa mọi thứ cũng như có được tất cả lịch sử, tất cả những thay đổi.
Vì vậy, trong một trường hợp điển hình hơn khi bạn có nhiều commit với nhánh của bạn, nhiều commit với nhánh chính, thì trong trường hợp đó, Git cần phải thực hiện nhiều công việc hơn một chút. Trước tiên thì nó cần phải khám phá xem, tổ tiên chung của các nhánh đó là gì? và sau đó nó cần phải tích hợp những thay đổi đó với nhau. Và cuối cùng, bạn nhận được một commit hợp nhất với tất cả các thay đổi giữa hai nhánh này.
Trong một tình huống như thế này, như đã đề cập, tất cả lịch sử được bảo tồn. Điều này có thể thực hiện được vì các chi nhánh đã được biết đến, đã được commit ... Nhưng với rất nhiều nhà phát triển, có thể xảy ra rằng bạn có một lịch sử commit rất lớn, rất nhiều thay đổi. Và trong nhiều trường hợp, điều này là không mong muốn hoặc có thể có một nhánh không được đồng bộ hóa với kho lưu trữ từ xa. Vì vậy, trong trường hợp như vậy, nó sẽ không thể làm điều đó như thế này. Vì vậy, bạn cần phải sử dụng một kỹ thuật khác, thay vì thực hiện việc hợp nhất đơn giản thì rebasing là điều bạn thường làm khi bạn có một chi nhánh đã tồn tại trong một thời gian ngắn, thậm chí có thể không được commit với kho lưu trữ từ xa và bạn vẫn tích hợp những thay đổi đó. Nhưng lịch sử của kho lưu trữ đó không có thông tin về nhánh tồn tại ngắn ngủi đó.
Sau đó, một trong những cuối cùng là cherrypicking. Cherrypicking là khi bạn có một commit, nó luôn bao gồm một hoặc nhiều đối tượng. Vì vậy, nếu một nhà phát triển có những thay đổi cần thiết để tích hợp được thực hiện dưới dạng một commit, trong trường hợp đó, bạn có thể sử dụng lệnh git cherrypick và nói “vui lòng tích hợp commit cụ thể này vào nhánh khác của tôi”. Vì vậy, một lần nữa, kết quả cuối cùng là mọi thứ đã được thực hiện ở đó là một phần của nhánh chính đó.
Đây là về merge, về commit công việc từ những người khác nhau. Bạn cần phải cẩn thận về những sự hợp nhất đó. Bởi vì ngay cả khi không có lỗi hợp nhất, nếu không có vấn đề hợp nhất, bạn vẫn cần phải kiểm tra mọi thứ. Bởi vì nó có thể xảy ra, chẳng hạn như đồng nghiệp của bạn, vì bất kỳ lý do gì, có thể thay đổi một cái gì đó trong code của bạn mà bạn không mong đợi. Vì vậy, có thể xảy ra rằng phần code của bạn không hoạt động hoặc bản thân ứng dụng không hoạt động. Vì vậy, bạn luôn cần phải kiểm tra.
Phần hay về Git là bạn có khả năng hoàn tác. Vì vậy, khi một điều gì đó đã được commit, có nhiều cách để hoàn tác công việc đó. Vì vậy, việc đầu tiên là Reset. Đặt lại là khi bạn muốn hoàn tác nhiều commit.
Bạn có nhiều cách để đặt lại hoặc khôi phục cài đặt gốc. Khi khôi phục cài đặt gốc, về cơ bản bạn đang quên một số thay đổi. Chúng vẫn ở đó, nhưng bạn đã quên chúng đi. Sau đó, bạn đã thiết lập lại hỗn hợp và thiết lập lại mềm. Vì vậy, đây là về nhiều hơn một commit duy nhất.
Nếu bạn chỉ có một commit, bạn cần hoàn tác commit đó, chẳng hạn như từ một nhà phát triển hoặc một trong các commit của bạn, những gì bạn có thể làm là sử dụng lệnh git revert và chỉ định ID của commit đó. Và kho lưu trữ sẽ trở lại trạng thái như trước khi commit. Vì vậy, đây thường là cách tiếp cận được ưa thích và điều này rất cần thiết nếu ai đó quyết định, có thể, xóa quá nhiều hoặc có thể thêm quá nhiều.
Trong nhiều trường hợp, việc hoàn nguyên sau đó để sửa những thứ đó theo cách thủ công sẽ dễ dàng hơn. Vì vậy, thay vì trước tiên xóa nhiều thứ và sau đó sao chép chúng trở lại, tốt hơn là chỉ sử dụng lệnh git revert. Hoặc trong một số trường hợp, bạn chỉ cần kiểm tra tệp mà bạn muốn lấy từ phiên bản trước.
Và phần cuối cùng là về các chi nhánh ở xa, một nhánh từ xa giống như một con trỏ. Vì vậy, với chi nhánh từ xa, kho lưu trữ của bạn biết các kho lưu trữ khác nằm ở đâu? Để sử dụng chúng, bạn cần sử dụng lệnh git remote add. Bạn chỉ định một bí danh cho kho lưu trữ từ xa và vị trí của chúng, sau đó bạn có thể kiểm tra từ đó. Ví dụ, bạn có thể tạo một chi nhánh mới, chi nhánh cục bộ của bạn, đang theo dõi chi nhánh từ xa.
Thông thường, khi bạn có các chi nhánh ở xa, bạn không phải commit ở đó. Bạn nên coi các nhánh từ xa là kho chỉ đọc. Nên khi bạn muốn thực sự làm việc trên nhánh từ xa, bạn cần tạo nhánh cục bộ của mình và cách đơn giản nhất là sử dụng lệnh git checkout với option -track.
Bạn chỉ định tên từ xa đó và nhánh được cấu hình trên kho lưu trữ từ xa. Và sau đó bạn nhận được bản sao cục bộ của chi nhánh đó nơi bạn làm việc và sẽ commit nó. Cuối cùng, bạn chỉ cần đẩy các thay đổi của mình vào điều khiển từ xa. Và bằng cách này, các thay đổi của bạn được đồng bộ hóa. Như vậy bạn thấy rằng Git là một công cụ rất mạnh, rất linh hoạt. Nó phù hợp với CI / CD, để tích hợp liên tục, phân phối liên tục bởi vì ở đó, dự kiến sẽ có rất nhiều thay đổi, thậm chí có thể nhiều thay đổi mỗi giờ, v.v.
Bạn cũng có hỗ trợ cho các thẻ, thẻ là cần thiết khi bạn muốn tạo một bản dựng ứng dụng của mình từ một thời điểm cụ thể. Bởi vì sau đó các thẻ đó cũng có thể được sử dụng như một phần của kiểm soát phiên bản. Vì vậy, khi có lỗi trong ứng dụng của bạn, vì ID từ Git được bao gồm trong phiên bản, thì mọi người khác đều có thể thấy, trạng thái của kho lưu trữ tại thời điểm đó là gì? Vì vậy, nó dễ dàng hơn để theo dõi lỗi.
Git là Hệ thống kiểm soát phiên bản phân tán (VCS) mà bạn có thể sử dụng để theo dõi và quản lý môi trường phát triển. Mỗi thành viên trong nhóm của bạn có một môi trường Git cục bộ riêng biệt và có thể đóng góp mã hoặc các tệp dự án khác vào kho lưu trữ từ xa chung.
Git theo dõi tất cả các thay đổi của các tệp bằng cách sử dụng một loạt các đối tượng Git nhỏ, được gọi là các commit, được liên kết với nhau thành một nhánh. Những commit đó nhẹ và bao gồm hầu hết các con trỏ đến các đối tượng Git khác, như snapshots, files và parent commits. Các đối tượng thực tế được lưu trữ riêng biệt trong một hệ thống file có thể xác định địa chỉ nội dung nhanh chóng và có thể dễ dàng truy cập bằng các con trỏ đó. Điều đó làm cho việc tạo, quản lý và chuyển đổi các chi nhánh trở nên nhanh chóng và dễ dàng.
Hỗ trợ phân nhánh hiệu quả là nền tảng cho các quy trình phát triển phân nhánh và hợp nhất thường xuyên. Về mặt này, Git là một kết hợp hoàn hảo cho các hoạt động tích hợp liên tục và triển khai liên tục (CI / CD).
Mặc dù Git sử dụng máy chủ như một điểm cộng tác tập trung, mọi kho lưu trữ cục bộ đều có bản sao riêng của các tệp dự án. Điều đó cho phép bạn có toàn quyền kiểm soát môi trường địa phương của mình và làm việc độc lập theo tốc độ của bạn. Tuy nhiên, Git theo dõi và kiểm soát mọi thay đổi cá nhân của cộng tác viên và khi bạn quyết định đồng bộ hóa với kho lưu trữ từ xa hoặc hợp nhất công việc của mình với các nhánh khác nhau, Git sẽ hướng dẫn bạn quy trình tích hợp mã và giải quyết xung đột.
Kiến trúc Git bao gồm kho lưu trữ từ xa và một số môi trường Git cục bộ phân tán, trong đó mỗi môi trường bao gồm kho lưu trữ cục bộ, khu vực dàn dựng và thư mục làm việc:
• Kho lưu trữ từ xa: Kho lưu trữ từ xa là nơi chứa các file của dự án và là nơi tất cả các bản sao cục bộ khác được lấy từ đó. Nó có thể được lưu trữ trên một máy chủ riêng nội bộ hoặc được lưu trữ trên một kho lưu trữ công cộng như GitHub hoặc BitBucket.
• Kho lưu trữ cục bộ: Kho lưu trữ cục bộ là một bản sao của kho lưu trữ từ xa nơi các commit được lưu trữ trên máy cục bộ của mỗi người. Nó cũng có thể bao gồm các nhánh bổ sung mà bạn đã tạo cục bộ và quyết định không chia sẻ với những người khác. Các commit mà bạn đã thực hiện cục bộ được đồng bộ hóa với các kho lưu trữ khác bằng cách sử dụng các lệnh git fetch, git pull và git push.
• Thư mục làm việc: Thư mục làm việc là thư mục hệ thống tệp thực tế được điều khiển bởi Git. Nó là một hộp cát nơi bạn làm công việc thực tế. Các file được Git theo dõi liên tục được so sánh với snapshot được tìm thấy trong khu vực Staging. Trong trường hợp có bất kỳ thay đổi nào, Git sẽ đánh dấu các tệp đó bằng cờ đã sửa đổi. Các tệp mới hoặc đã thay đổi khác được đánh dấu là chưa được theo dõi. Bạn có thể kiểm tra trạng thái của các file bằng lệnh git status.
• Khu vực giai đoạn: Khu vực giai đoạn là nơi đặt tất cả các thay đổi bạn muốn cho lần commit tiếp theo. Bạn có thể sử dụng lệnh git add để tạo các file từ thư mục làm việc. Bằng cách di chuyển các file chưa được theo dõi sang khu vực Staging, các tệp đó sẽ được theo dõi và được đưa vào các kiểm tra Git tiếp theo.
Với lệnh git commit, bạn di chuyển snapshot của khu vực Staging vào kho lưu trữ cục bộ. Ở đó nó được lưu dưới dạng commit mới trong nhánh hiện đang được sử dụng. Các tập tin không được sắp xếp không được bao gồm trong commit.
Bằng cách kiểm tra hoặc hợp nhất một nhánh khác, bạn ghi đè lên thư mục làm việc. Nếu bạn vẫn còn một số file đã sửa đổi hoặc theo giai đoạn, Git không cho phép bạn chuyển các nhánh.
