q1: Git fork là gì? Sự khác biệt giữa git fork, branch, clone?
- git fork: là bản sao của một kho lưu trữ (một kho lưu trữ mã nguồn của bạn trên github). Việc tạo kho lưu trữ cho phép bạn dễ dàng chỉnh sửa và thay đổi mã nguồn mà không ảnh hưởng đến nguồn gốc.
- git clone: Không giống như fork; nó là một bản sao cục bộ từ xa của một số kho lưu trữ. Khi bạn sao chép, bạn sao chép toàn bộ kho lưu trữ, bao gồm tất cả lịch sử và các nhánh.
- git branch: là một cơ chế để làm việc với các thay đổi trong một kho lưu trữ duy nhất để cuối cùng hợp nhất chúng với phần còn lại của mã. Chi nhánh là một cái gì đó nằm trong một repo. Về mặt khái niệm, nó thể hiện dòng chảy của sự phát triển.
q2: Sự khác biệt giữa “pull request” và “branch” là gì?
- branch: là một phiên bản mã riêng biệt.
- yêu cầu: là khi ai đó tìm nạp repo, tạo nhánh của riêng họ, thực hiện một số thay đổi và sau đó hợp nhất nhánh đó (với các thay đổi của họ trong repo của người khác).
q3: Sự khác biệt giữa “git pull” và “git fetch”?
Nói chung, git pull trước tiên sẽ thực hiện tìm nạp git, sau đó thực hiện hợp nhất git
- Khi bạn sử dụng pull git sẽ cố gắng tự động thực hiện công việc của bạn cho bạn. Vì vậy, git sẽ hợp nhất tất cả các cam kết trong nhánh mà bạn đang làm việc. Tự động hợp nhất các cam kết mà không cho phép bạn xem trước chúng. Nếu bạn không quản lý các chi nhánh của mình một cách cẩn thận, bạn có thể thường xuyên xảy ra xung đột.
- Khi bạn tìm nạp , git có thu thập bất kỳ cam kết nào từ nhánh đích và tồn tại trong nhánh hiện tại không? Lưu trữ chúng trong kho lưu trữ cục bộ. Tuy nhiên, nó sẽ không hợp nhất chúng với chi nhánh hiện tại của bạn. Điều này đặc biệt hữu ích nếu bạn cần cập nhật kho lưu trữ, nhưng nếu bạn cập nhật các tệp, nó có thể ảnh hưởng đến hoạt động của dự án. Để hợp nhất các cam kết vào nhánh chính của bạn, hãy sử dụng hợp nhất.
q4: Làm cách nào để khôi phục các cam kết trước đó trong git?
Giả sử bạn có 2 nhánh c, f (trong đó c là phần đầu của bạn và (f) là trạng thái của tệp của bạn)
- Kiểm tra lại các thay đổi trong cam kết:
Bây giờ b là người đứng đầu. Bởi vì bạn đã sử dụng -hard, tệp của bạn đã được đặt lại về trạng thái cam kết b.
- Hoàn tác cam kết nhưng vẫn giữ các thay đổi:
Bây giờ git sẽ di chuyển con trỏ đầu trở lại commit (b) và giữ nguyên tệp đó và trạng thái git sẽ hiển thị những thay đổi bạn đã đăng ký đối với c.
- Hoàn tác cam kết mà không thay đổi tệp và chỉ mục
Khi bạn ở trạng thái git, bạn sẽ thấy các tệp giống nhau trong chỉ mục như trước đây.
q5: “git cherry-pick” là gì?
Lệnh git cherry-pick thường được sử dụng để xem các cam kết cụ thể từ một nhánh trong repo của nhánh khác. Cách sử dụng phổ biến là cam kết chuyển tiếp hoặc cam kết ngược từ nhánh bảo trì đến nhánh phát triển.
Điều này hoàn toàn trái ngược với các cách tiếp cận khác như hợp nhất và giảm giá, thường áp dụng nhiều cam kết cho các nhánh khác nhau.
q6: Giải thích những ưu điểm của quy trình công việc phân nhánh
Quy trình công việc forking khác với các quy trình công việc git phổ biến khác. Thay vì sử dụng một kho lưu trữ phía máy chủ duy nhất làm cơ sở dữ liệu “trung tâm”, nó cung cấp cho mỗi nhà phát triển kho lưu trữ phía máy chủ của riêng họ. Các quy trình công việc được phân nhánh thường thấy nhất trong các dự án nguồn mở công khai.
Ưu điểm chính của quy trình làm việc forking là các đóng góp có thể được tích hợp mà không cần tất cả mọi người đẩy vào một kho lưu trữ trung tâm duy nhất, dẫn đến lịch sử dự án sạch sẽ. Các nhà phát triển đẩy đến các kho lưu trữ phía máy chủ của riêng họ và chỉ những người bảo trì dự án mới có thể đẩy đến các kho lưu trữ chính thức.
Khi các nhà phát triển hoàn thành một cam kết cục bộ, họ đẩy cam kết đến kho lưu trữ cục bộ của riêng họ, không phải kho lưu trữ chính thức. Sau đó, họ kéo yêu cầu đến repo chính, cho người bảo trì dự án biết rằng bản cập nhật đã sẵn sàng được tích hợp.
q7: Sự khác biệt giữa phần đầu, cây làm việc và chỉ mục, trong git?
- Cây làm việc / thư mục làm việc / vùng làm việc là cây thư mục của các tệp (nguồn) mà bạn xem và chỉnh sửa.
- Vùng chỉ mục / dàn dựng là một tệp / chỉ mục nhị phân lớn duy nhất trong /.git liệt kê tất cả các tệp trong nhánh hiện tại.
- head là tham chiếu đến lần cam kết cuối cùng trong nhánh hiện đã được kiểm tra.
q8: Hiển thị quy trình làm việc gitflow?
Quy trình làm việc gitflow sử dụng hai nhánh dài song song để ghi lại lịch sử của dự án, tổng thể và phát triển:
-
master – sẵn sàng phát hành, tất cả các nhánh đã được kiểm tra và phê duyệt đầy đủ (sẵn sàng sản xuất).
- hotfix – Một nhánh bảo trì hoặc “hotfix” để nhanh chóng vá các bản phát hành sản xuất. Các nhánh hotfix rất giống với các nhánh phát hành và tính năng, ngoại trừ chúng dựa trên chính thay vì phát triển.
development – là nhánh hợp nhất tất cả các nhánh tính năng và thực hiện tất cả các thử nghiệm. Chỉ hợp nhất với tổng thể sau khi kiểm tra kỹ lưỡng và hiệu chỉnh.
Tính năng
- – Mỗi tính năng mới phải nằm trong nhánh riêng của nó và có thể được đẩy đến nhánh phát triển dưới dạng một nhánh con.
q9: Khi nào sử dụng “git stash”?
Lệnh git stash nhận các thay đổi chưa cam kết của bạn (theo giai đoạn và không theo giai đoạn), lưu chúng để sử dụng sau này và lưu trữ chúng từ bản sao đang làm việc của bạn.
Cân nhắc:
Nếu chúng tôi nhận thấy rằng chúng tôi đã quên điều gì đó trong lần cam kết cuối cùng và bắt đầu làm việc trên nhánh tiếp theo trong cùng một nhánh, chúng tôi có thể sử dụng stash:
q10: Làm cách nào để xóa tệp khỏi git mà không xóa tệp đó khỏi hệ thống tệp?
Nếu bạn không cẩn thận khi thêm git, bạn có thể thêm các tệp mà bạn không muốn cam kết. Tuy nhiên, git rm sẽ xóa nó khỏi vùng dàn (chỉ mục) cũng như khỏi hệ thống tệp của bạn (cây làm việc), điều này có thể không phải là điều bạn muốn.
Sử dụng git reset:
. để thay thế
Điều này có nghĩa là git đặt lại
hoàn toàn khác với git add & lt; path & gt ;.
q11: Khi nào bạn sử dụng “git rebase” thay vì “git merge”?
Cả hai lệnh đều được thiết kế để kết hợp các thay đổi từ nhánh này sang nhánh khác.
Cân nhắc trước khi hợp nhất / giảm giá:
Sau khi kết hợp git master:
Sau git rebase master:
Khi nào sử dụng:
- Nếu bạn có bất kỳ câu hỏi nào, vui lòng sử dụng hợp nhất.
- Lựa chọn khôi phục hoặc hợp nhất tùy thuộc vào cách bạn muốn lịch sử của mình trông như thế nào.
Nhiều yếu tố cần xem xét:
1. Chi nhánh của bạn có nhận được các thay đổi do chia sẻ với các nhà phát triển khác bên ngoài nhóm (ví dụ: nguồn mở, công khai) không? Nếu vậy, vui lòng không rebase. Rebase sẽ phá vỡ các nhánh và trừ khi họ sử dụng lệnh git pull -rebase, repo của các nhà phát triển này sẽ bị ảnh hưởng / không nhất quán.
2. Các kỹ năng của nhóm phát triển là gì? Rebase là một hoạt động phá hoại. Điều này có nghĩa là nếu bạn không áp dụng nó một cách chính xác, bạn có nguy cơ mất cam kết và / hoặc phá vỡ sự thống nhất repo của các nhà phát triển khác.
3. Bản thân chi nhánh có đại diện cho thông tin hữu ích không? Một số nhóm sử dụng mô hình mỗi nhánh, trong đó mỗi nhánh đại diện cho một tính năng (hoặc sửa lỗi hoặc tính năng phụ, v.v.), nơi các nhánh giúp xác định các tập hợp các cam kết liên quan. Trong trường hợp của mô hình chi nhánh cho mỗi nhà phát triển, bản thân chi nhánh không truyền tải bất kỳ thông tin bổ sung nào. Không có hại trong việc phục hồi.
4. Bạn có muốn tiếp tục kéo đã hợp nhất vì bất kỳ lý do gì không? Hoàn nguyên một quá trình phục hồi khó hơn một chút và / hoặc không thể (nếu quá trình khôi phục xung đột) so với việc hoàn nguyên một hợp nhất. Sử dụng hợp nhất nếu bạn nghĩ rằng bạn có thể muốn hoàn nguyên.
Tham khảo: https://dev.to/aershov24/11-painful-git-interview-questions-you-will-cry-on-1n2g