q1: git fork là gì? sự khác biệt giữa git fork, branch và clone?
- git fork: là bản sao của repository (nơi 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ác với 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 đang 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à cơ chế quản lý các thay đổi trong một kho lưu trữ để cuối cùng hợp nhất chúng với phần còn lại của mã. nhánh là một cái gì đó nằm trong một kho lưu trữ. Về mặt khái niệm, nó đại diện cho một dòng phát triển.
q2: sự khác biệt giữa “pull request” và “branch”?
- nhánh: là một phiên bản mã riêng biệt.
- yêu cầu: là khi ai đó lấy một kho lưu trữ, 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 đó (đặt các thay đổi của họ vào kho lưu trữ mã của người khác).
q3: sự khác biệt giữa “git pull” và “git fetch”?
nói chung, git pull thực hiện tìm nạp git theo sau là hợp nhất git
- Khi bạn sử dụng pull , git sẽ tự động cố gắng thực hiện công việc cho bạn. vì vậy git sẽ hợp nhất mọi cam kết trên 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ý chặt chẽ các chi nhánh của mình, 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 các cam kết của chi nhánh mục tiêu tồn tại trong chi nhánh và cửa hàng hiện tại của bạn không chúng trong kho lưu trữ cục bộ của bạn. tuy nhiên, nó không hợp nhất chúng vào 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ữ của mình, nhưng đang làm việc trên một dự án có thể dễ dàng bị ảnh hưởng nếu bạn cập nhật tệp của mình. để hợp nhất các cam kết vào chi nhánh chính của bạn, hãy sử dụng hợp nhất.
q4: cách hoàn nguyên cam kết trước đó trong git?
giả sử bạn có 2 nhánh c, f (trong đó c là tiêu đề và (f) là trạng thái tệp của bạn)
- để hủy bỏ các thay đổi khi cam kết:
bây giờ b là đầu. bởi vì bạn đã sử dụng -hard, các tệp của bạn được đặt lại về trạng thái cam kết b.
- để hoàn tác một 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 các tệp và trạng thái git hiển thị những thay đổi bạn đã đẩy trong c.
- để hoàn tác cam kết của bạn mà không thay đổi các tệp và chỉ mục của bạn
khi bạn thực hiện trạng thái git, bạn sẽ thấy rằng các tệp giống nhau nằm 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ể cho một nhánh trong kho lưu trữ trên một 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 chuyển cảng từ chi nhánh bảo trì đến phát triển.
Điều này trái ngược với các hình thức khác, chẳng hạn như hợp nhất và giảm giá, thường áp dụng nhiều cam kết cho một chi nhánh khác.
q6: Giải thích các lợi ích của quy trình làm 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 để hoạt động như 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ọ. quy trình 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 phân nhánh là các đóng góp có thể được tích hợp mà không cần 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 kiểm tra kho lưu trữ phía máy chủ của riêng họ và chỉ người duy trì dự án mới có thể kiểm tra 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ọ gửi yêu cầu đến kho lưu trữ chính, thông báo cho người bảo trì dự án 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 head, work tree và index, trong git?
- cây làm việc / thư mục làm việc / không gian làm việc là một cây thư mục gồm các tệp (nguồn) mà bạn có thể xem và chỉnh sửa.
- vùng chỉ mục / dàn dựng là một tệp nhị phân đơn lớn trong /.git / index, liệt kê tất cả các tệp trên nhánh hiện tại.
- head là tham chiếu đến lần cam kết cuối cùng trên 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 song song dài để ghi nhật ký, làm chủ và phát triển lịch sử dự án:
-
chính: luôn sẵn sàng hoạt động, với tất cả các chi nhánh đã được kiểm tra và phê duyệt đầy đủ (sẵn sàng để sản xuất).
- hotfix: Các nhánh bảo trì hoặc “hotfix” được sử dụng để vá nhanh các bản phát hành sản xuất. các nhánh sửa đổi gần giống như các nhánh phát hành và các nhánh tính năng, ngoại trừ chúng là dựa trên tổng thể thay vì dựa trên phát triển.
development: Đây là nhánh mà tất cả các nhánh tính năng được hợp nhất và là nơi tất cả các thử nghiệm được thực hiện. chỉ khi mọi thứ được kiểm tra kỹ lưỡng và sửa chữa thì mới có thể hợp nhất với bản chính.
Tính năng
- : Mỗi tính năng mới phải nằm trên nhánh riêng của nó, có thể được đẩy đến nhánh phát triển làm nhánh con của nó.
p9: khi nào sử dụng “git stash”?
Lệnh git stash nhận các thay đổi chưa được cam kết của bạn (cả được lưu trữ và chưa được phân giai đoạn), lưu chúng để sử dụng sau này và sau đó chuyển đổi chúng từ bản sao đang làm việc của bạn.
xem xét:
chúng tôi có thể sử dụng tính năng ẩn nếu chúng tôi nhận thấy mình đã quên điều gì đó trong lần cam kết cuối cùng và bắt đầu làm việc với nhánh tiếp theo trên cùng nhánh đó:
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 của bạn?
Nếu bạn không cẩn thận 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ư hệ thống tệp của bạn (cây làm việc), điều này có thể không như 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”?
Hai lệnh này được thiết kế để tích 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 / cải tổ lại:
sau git merge master:
sau git rebase master:
khi nào sử dụng:
- nếu nghi ngờ, hãy sử dụng hợp nhất.
- việc chọn đặt lại cơ sở hoặc hợp nhất dựa trên 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 khi chia sẻ với các nhà phát triển khác bên ngoài nhóm của bạn (ví dụ: nguồn mở, công khai) không? nếu vậy, không vượt qua. rebase phá hủy nhánh và kho lưu trữ của các nhà phát triển đó sẽ bị ảnh hưởng hoặc không nhất quán trừ khi họ sử dụng lệnh git pull -rebase.
2. là kỹ năng của nhóm phát triển? rebase là một hoạt động phá hủy. điều đó có nghĩa là nếu bạn không áp dụng đúng cách, bạn có thể mất cam kết và / hoặc phá vỡ đơn vị lưu trữ 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 chi nhánh theo từng nhánh, trong đó mỗi nhánh đại diện cho một tính năng (hoặc sửa lỗi, tính năng phụ, v.v.) trong trường hợp của mô hình theo từng 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ó gì sai khi thay đổi đế.
4. bạn có muốn đảo ngược các trích xuất đã hợp nhất vì một số lý do? việc đảo ngược một rebase hơi khó hơn và / hoặc không thể (nếu rebase xung đột) so với việc đảo ngược một hợp nhất. nếu bạn nghĩ rằng bạn có thể muốn hoàn nguyên, hãy sử dụng hợp nhất.
tham khảo: https://dev.to/aershov24/11-painful-git-interview-questions-you-will-cry-on-1n2g
