Chúng tôi cung cấp các trang này để cố gắng làm cho cuộc sống lập trình của bạn dễ dàng hơn. Trang tài nguyên của chúng tôi cung cấp tổng quan. Bạn có thể xem danh sách đầy đủ các mẹo và công cụ Git của chúng tôi tại đây
Chúng tôi có những công cụ miễn phí này
Tôi thích bất kỳ công cụ nào giúp cuộc sống của tôi dễ dàng hơn. Điều này là hoàn hảo, vừa đủ lượng kiểm soát. Không nhiều không ít. Dễ dàng bắt đầu, đẩy và khôi phục các thay đổi. Nó không có trí tuệ.
Hayden T.
Vì công việc của các lập trình viên đã trở thành làm việc theo nhóm – nghĩa là thực tế luôn luôn – nên cần phải đồng bộ hóa mã do những người khác nhau tạo ra. Hiện tại, thế giới được vi tính hóa đến mức ngay cả những công ty không xử lý phần mềm, ngày càng thường xuyên có bộ phận CNTT nội bộ phục vụ nhu cầu của riêng họ. Kết quả là chúng tôi ngày càng có nhiều nhà phát triển hơn và điều đó có nghĩa là ngày càng có nhiều mã để đồng bộ hóa và nó lặp đi lặp lại nhiều lần
Khi làm việc trên Linux, Linus Torvalds đã cảm nhận được vấn đề này một cách khó khăn và đã phát triển hệ thống Git, giúp đồng bộ hóa mã dễ dàng hơn nhiều và do đó, tăng tốc độ sản xuất của nó. Git được biết đến như một hệ thống kiểm soát phiên bản phân tán. Nhưng điều đó có nghĩa gì? . Nhờ đó, chúng tôi có thể thực hiện bất kỳ thay đổi cục bộ nào, thêm hoặc xóa mã, tạo nhánh mới, v.v. Đây cũng là một tính năng bảo mật vì trong trường hợp xảy ra lỗi, chúng tôi có thể khôi phục kho lưu trữ chỉ dựa trên một phiên bản cục bộ. Mặc dù tôi sẽ không dựa vào điều đó và chúng ta phải luôn có công cụ sao lưu phù hợp
Còn một điều nữa liên quan đến kiến trúc phân tán như vậy – xác định bản sao nào sẽ là bản chính. Tất cả những người khác sẽ tích hợp vào nó. Các thay đổi của chúng tôi sẽ được tải lên ở đó và chúng tôi sẽ tải xuống các thay đổi khác từ đó. Nhờ giải pháp này, mỗi bản sao cục bộ chỉ biết về một kho lưu trữ bên ngoài và không phải tích hợp với bất kỳ kho lưu trữ nào khác. Giải pháp này được vay mượn từ các giải pháp tập trung, chẳng hạn như SVN, nhưng cần lưu ý rằng đây chỉ là một tiêu chuẩn và thông lệ, không phải là một tính năng hoặc hạn chế của chính công cụ Git
Quy trình công việc Git
Vì chúng ta đang nói về các tiêu chuẩn và thực tiễn, nên bạn nên làm quen với các loại quy trình công việc Git khác nhau. Điều quan trọng là bất kể quy trình công việc được sử dụng là gì, việc đồng bộ hóa các thay đổi có hai thao tác – tải xuống các thay đổi mới từ máy chủ [kéo] và gửi các thay đổi của chúng tôi đến đó [đẩy]. Nếu mọi lập trình viên tạo các tệp mới, không có vấn đề gì ở đây, họ tải xuống mã do người khác tạo và thêm những gì họ tự tạo. Tuy nhiên, cuộc sống thực không hoàn hảo và điều này hiếm khi xảy ra. Thông thường, nhóm làm việc trên cùng một tệp, điều này có nguy cơ ghi đè lên các thay đổi do người khác thực hiện. Việc sử dụng quy trình công việc phù hợp, được đề cập trong liên kết ở trên, cho phép chúng tôi giải quyết vấn đề
Các lệnh gọi Git push và git pull
Để lại quy trình làm việc phía sau chúng tôi, hãy phân tích chính xác cơ chế đồng bộ hóa dữ liệu trong Git hoạt động như thế nào. Hãy bắt đầu với những gì xảy ra khi chúng tôi gửi các thay đổi của mình. Hoạt động này được gọi là 'đẩy'. Đây là một lạc đề nhỏ về các chiến lược hợp nhất. Nếu câu chuyện là tuyến tính và việc hợp nhất thêm một cam kết khác ở cuối, thì cái gọi là chuyển tiếp nhanh sẽ xảy ra. Nó chỉ thêm các xác nhận đã được gửi và cập nhật nhánh để bây giờ nó trỏ đến các thay đổi mới được thêm vào. Tình huống thứ hai là khi chúng ta có lịch sử phân nhánh và có thêm cái gọi là cam kết hợp nhất. Hãy xem nó trong các hình ảnh dưới đây
Hãy quay lại thao tác “đẩy”. Chỉ có thể thực hiện được nếu có thể thực hiện chuyển tiếp nhanh. Các thay đổi cục bộ của chúng tôi nằm trong kho lưu trữ từ xa và tất cả các thành viên dự án khác có thể tải xuống từ bây giờ. Nếu không thể hợp nhất chuyển tiếp nhanh, Git sẽ không cho phép chúng tôi đồng bộ hóa như hiện tại và chúng tôi sẽ nhận được thông báo lỗi. Thông thường, kết quả là chúng tôi phải tải xuống cục bộ phiên bản mới nhất của mã, thực hiện hợp nhất trên máy của chúng tôi và chỉ sau đó cố gắng gửi các thay đổi của chúng tôi đến kho lưu trữ từ xa
Tôi đã đề cập tải xuống phiên bản mã mới nhất. Đây là mục đích của thao tác “kéo”. Trên thực tế, phải mất hai bước, đầu tiên là thao tác tìm nạp, tải mã từ kho lưu trữ từ xa về cái gọi là nhánh từ xa, là bản sao cục bộ của nội dung bên ngoài. Và sau đó hợp nhất với nhánh làm việc cục bộ được thực hiện. Sau đó, các thay đổi của chúng tôi sẽ được hợp nhất [hoặc không, thêm vào đó trong giây lát] và chúng tôi có phiên bản mã hiện tại, giống với trạng thái trong kho lưu trữ từ xa
Repos và siêu dữ liệu của bạn an toàn đến mức nào?
Bắt đầu 14 ngày dùng thử GitProtect miễn phí
Hợp nhất xung đột
Git có thể tự động hợp nhất các thay đổi một cách hiệu quả, nhưng điều này không phải lúc nào cũng khả thi. Bởi vì điều gì sẽ xảy ra khi hai người đồng thời thay đổi tên của cùng một tệp và thành hai tên hoàn toàn khác nhau? . Trong trường hợp các thay đổi không thể được đánh giá một cách rõ ràng và tự động kết hợp, thì có cái gọi là "xung đột hợp nhất". Đây là tình huống trong đó thao tác hợp nhất bị gián đoạn giữa quá trình thực thi và cần phải thực hiện thao tác thủ công để kết thúc xung đột. Tại thời điểm này, tôi sẽ bỏ qua chủ đề về các công cụ đồ họa có sẵn để tạo điều kiện thuận lợi cho nhiệm vụ này và các chi tiết về cách giải quyết xung đột
Điều quan trọng là xung đột có thể được giải quyết theo hai cách – làm gián đoạn hoạt động và trở về trạng thái trước khi tùy chọn hợp nhất được chạy hoặc chọn các thay đổi sẽ được chấp nhận và phê duyệt chúng bằng thao tác cam kết. Cái gọi là cam kết hợp nhất mới, giới thiệu các thay đổi không có xung đột đối với kho lưu trữ. Bây giờ chỉ cần gửi một cam kết mới đến kho lưu trữ bên ngoài và tình hình đã được kiểm soát
Một phương pháp hiệu quả để tránh xung đột [hay đúng hơn là giảm thiểu số lượng của chúng] là đồng bộ hóa thường xuyên. Điều này giúp giảm số lượng xung đột và ngay cả khi chúng xảy ra, chúng thường dễ giải quyết hơn. Nhưng hãy xem xét một điều - git pull có thể ghi đè lên các thay đổi cục bộ không? . không theo mặc định. Hãy nhớ rằng trong trường hợp thao tác "kéo", thực tế có hai thao tác - tìm nạp và hợp nhất. Cuối cùng, ngay cả khi các thay đổi của chúng tôi được thay thế cục bộ, nó sẽ được thực hiện thông qua một cam kết hợp nhất, vì vậy những gì chúng tôi có trong mã trước đó sẽ vẫn tồn tại trong các cam kết trước đó. Chúng tôi không thể nói về việc ghi đè ở đây, vì mã của chúng tôi chưa biến mất khỏi kho lưu trữ. Tuy nhiên, xin nhắc lại, đây là trường hợp của hành vi mặc định [và phổ biến nhất]. Vì vậy, hãy vui vẻ và cố gắng thực sự ghi đè lên một cái gì đó
Ghi đè và tham số "bắt buộc"
Có từ kỳ diệu 'lực lượng' trong Git, là tham số của nhiều lệnh. Nó vừa bổ ích vừa nguy hiểm, tùy thuộc vào việc sử dụng nó đúng cách và có ý thức hay không. Nói chung, tham số này cho phép chúng tôi buộc một thao tác mà Git thường không muốn thực hiện. Có thể có nhiều lý do ở đây, e. g. lịch sử không khớp tại thời điểm thực hiện đẩy. Trước đó, tôi đã mô tả cách hoạt động của các hoạt động “đẩy” và “kéo” theo mặc định, nhưng bây giờ hãy kiểm tra xem điều gì sẽ xảy ra khi chúng ta thêm tham số mới này vào chúng. Vậy làm thế nào để buộc git pull?
Lực kéo Git thực sự chỉ ảnh hưởng đến một trong các thành phần của nó, cụ thể là thao tác tìm nạp. Trong một trường hợp, chính xác. Chúng ta hãy xem tài liệu Git cho thao tác “fetch force” trong giây lát
When git fetch is used with : refspec it may refuse to update the local branch as discussed in the part below. This option overrides that check.
And further, in the section, we can find an example that explains the and parameters above:
tag means the same as refs/tags/:refs/tags/; it requests fetching everything up to the given tag.
The remote ref that matches is fetched, and if is not an empty string, an attempt is made to update the local ref that matches it.
So here we have our potential use of the –force flag. As described in the documentation, until we specify the second parameter manually, the parameters of and are the same and there should be no error here. This is the default behavior. However, if we intentionally want to download the content of another branch under a given branch, so our parameter values will be different, there may be a synchronization problem here and Git will refuse to perform such an operation. Here, our new friend comes to the rescue, which will force such a step to be performed despite the differences in both branches. However, we must be sure what we are doing, because this step will override our local changes. So the answer to ‘how to force pull in git?’ is simple – use the “force” parameter at the end of our statement.
Lực đẩy git làm gì?
Hãy chuyển sang hoạt động tiếp theo. Lực đẩy git làm gì? . Cái nào có khả năng nguy hiểm hơn nhiều. Theo mặc định, Git sẽ chỉ đẩy nếu nó thành công trong việc hợp nhất chuyển tiếp nhanh đã nói ở trên. Trong mọi trường hợp khác, chúng tôi sẽ gặp lỗi và hoạt động sẽ được khôi phục. Điều này có cấu trúc tốt vì nó buộc chúng tôi phải giữ trật tự trong lịch sử và đồng bộ hóa cục bộ trước khi chúng tôi có thể gửi mã của mình đi
Chà, hôm nay chúng ta không nói về những hành động 'bình thường', mà là về cách tránh chúng bằng lá cờ ma thuật của chúng ta. Việc thêm "lực lượng" trong thao tác "đẩy" sẽ khiến Git chấp nhận mọi thay đổi của chúng ta, bất kể chúng ta đã thực hiện lộn xộn như thế nào trong lịch sử cam kết. Chúng ta chỉ nói “làm đi nào” và ghi đè lên câu chuyện mãi mãi. Điều này rất nguy hiểm vì nó tạo ra nguy cơ mất một lượng lớn dữ liệu và thông thường thao tác như vậy là không thể chấp nhận được trong một kho lưu trữ được cấu hình tốt. Hãy để tôi đăng một trích dẫn khác từ tài liệu Git về chủ đề này
Cờ này […] có thể khiến kho lưu trữ từ xa mất các xác nhận;
bùng nổ. Nếu chúng tôi làm điều gì đó như thế này, tại thời điểm này, lịch sử kho lưu trữ của chúng tôi đã bị ghi đè và chúng tôi có khả năng bị mất một số dữ liệu
Lực đẩy git có tệ không?
Tôi sẽ trả lời theo cách yêu thích của mình – điều đó còn tùy. Nói chung, như đã thỏa thuận, nó là một công cụ rất nguy hiểm và phải được sử dụng một cách khôn ngoan. Nhưng có thể gọi là xấu không? . Tôi sẽ cho bạn một ví dụ đơn giản từ kinh nghiệm của bản thân. Tôi dạy lập trình cho mọi người và chúng tôi thường sử dụng kho Git cho các hội thảo. Mỗi xưởng đều có repo riêng, đây không phải là những dự án lớn nhưng được làm với số lượng lớn. Thông thường, khi một cái mới được tạo, đã có một số cam kết trong đó, e. g. với tệp README hoặc đại loại như thế. Chà, tôi đã có một dự án được tạo cục bộ mà tôi muốn đặt tất cả vào kho lưu trữ này và không gây rối với bất kỳ sự hợp nhất thay đổi nào. Tham số "lực lượng" hỗ trợ bạn. Kết quả là tôi xóa mọi thứ trong kho lưu trữ này cho đến nay và chỉ đặt ở đó những gì tôi đã chuẩn bị trước đó. Một ví dụ đơn giản nhưng cho thấy công dụng và nguyên lý hoạt động của công cụ này
Ngoài ra còn có một sự khác biệt cơ bản giữa việc sử dụng git push force và git pull force. Ghi đè các thay đổi trong khi tải xuống sẽ sửa đổi bản sao cục bộ của chúng tôi, vì vậy đây không phải là một hành động nguy hiểm đối với toàn bộ dự án. Ít nhất đến một điểm. Trong trường hợp thao tác “đẩy”, vấn đề nghiêm trọng hơn vì nó ảnh hưởng đến tất cả mọi người sử dụng kho lưu trữ này và có thể khá lộn xộn. Khắc phục sự cố như vậy có thể mất rất nhiều thời gian và căng thẳng. Và tiền nữa. Sẽ không có gì ngạc nhiên với bất kỳ ai khi tôi đề cập đến sự cần thiết phải tạo bản sao lưu
Tóm lược
Vì vậy, hãy đặt tất cả lại với nhau. Việc sử dụng tùy chọn “bắt buộc” có rủi ro không? . Rất nhiều, đặc biệt là trong trường hợp thao tác “đẩy”. Tôi có cần quyền đặc biệt để sử dụng tùy chọn này không? . Và các chi nhánh quan trọng nên có sự bảo mật như vậy nếu chúng tôi thực hiện các dự án của mình một cách nghiêm túc. Đây được gọi là các nhánh được bảo vệ và nó cho phép bạn thực hiện các quy tắc khác nhau, bao gồm bảo vệ chống lại tùy chọn "bắt buộc". Và nó là một thực tế xấu để sử dụng tùy chọn này?
Cuối cùng – chúng ta có cần sao lưu không? . Nó luôn luôn cần thiết và chúng ta nên luôn nhớ về nó. Đặc biệt là khi chúng ta chơi trò chơi rất nguy hiểm là ghi đè lịch sử bằng vũ lực