Khi nào tôi cần thực hiện “git pull”, trước hoặc sau “git add, git commit”?


93

Đúng cách là gì?

git add foo.js
git commit foo.js -m "commit"
git pull
git push

Hoặc là

git pull
git add foo.js
git commit foo.js -m "commit"
git push

Hoặc là

git add foo.js
git pull
git commit foo.js -m "commit"
git push

CẬP NHẬT:

Tôi quên đề cập rằng trong trường hợp này, tôi sử dụng git addđể tạo thành một tệp được theo dõisửa đổi . Không đưa một tệp hoàn toàn mới vào kho lưu trữ. Điều này có thay đổi thứ tự các lệnh không?


Câu trả lời:


95

Tôi nghĩ rằng cách tốt nhất để làm điều này là:

Lưu trữ các thay đổi cục bộ của bạn:

git stash

Cập nhật chi nhánh lên mã mới nhất

git pull

Hợp nhất các thay đổi cục bộ của bạn vào mã mới nhất:

git stash apply

Thêm, cam kết và đẩy các thay đổi của bạn

git add
git commit
git push

Theo kinh nghiệm của tôi, đây là con đường ít kháng cự nhất với Git (dù sao thì trên dòng lệnh).


4
Bạn có thể giải thích tại sao điều này tốt hơn? Điều này tránh được những vấn đề gì? Đặc biệt, tại sao điều này lại tốt hơn so với commit> pull> push đơn giản? (Tôi cảm thấy đây có thể là câu trả lời tốt nhất, nhưng không có đủ thông tin ngay bây giờ để thậm chí được coi là một câu trả lời hay.)
dallin

7
Có lẽ điều này quá giai thoại nhưng tôi luôn thấy cách tiếp cận này (trên dòng lệnh thay vì với một cái gì đó như sourcetree) dễ dàng hơn nhiều. Thực hiện cam kết và sau đó kéo, trong khi làm việc trong một nhóm lớn, luôn dẫn đến xung đột hợp nhất lớn vì git không tốt trong việc hợp nhất các thay đổi của tôi thành một tệp với tệp đến. Bằng cách lưu trữ, nó cho phép tôi kéo các thay đổi mới và sau đó sử dụng mã đã cập nhật làm cơ sở để thêm các thay đổi của tôi vào. Đối phó với các xung đột dễ dàng hơn vì chúng rõ ràng hơn với tôi (vì những thay đổi của tôi bây giờ là xung đột). Trong nhận thức muộn màng, có thể tình huống của tôi dễ dàng hơn.
johnjo 30/07/18

1
Vì vậy, nó giống như một loại đại loại "Làm thế nào để bạn ăn một con voi? Mỗi lần cắn một miếng". tức là Chia nhỏ quy trình thành một vài bước nữa để đơn giản hóa việc hợp nhất để có ít thay đổi hơn và có thể rõ ràng hơn. Có ý nghĩa.
dallin

Có cần thêm git ở đây không? Nếu tất cả các tệp đã được thêm vào dàn!
Sharp Edge

Còn nếu bạn không sử dụng git stash?
Aaron Franke

76

kéo = tìm nạp + hợp nhất.

Bạn cần phải cam kết những gì bạn đã làm trước khi hợp nhất.

Vì vậy, kéo sau khi cam kết.


8
Điều này có nghĩa là bạn sẽ thực hiện thêm một cam kết cho mỗi cam kết mà bạn thực hiện và làm cho bản repo trở nên cẩu thả? Ngoài ra, thông báo cam kết ban đầu của bạn cũng kết thúc bằng một nhận xét hợp nhất mỗi lần. Nếu vậy, tôi có xu hướng sử dụng phương pháp lưu trữ được đề cập bên dưới bởi @johnjo.
Thứ Hai, tờ giấy

3
@DanielM Có, có thêm một cam kết cho hợp nhất (với một thông báo cam kết mặc định rõ ràng). Mặc dù vậy, đây là một điều khá tốt vì nó cho phép bạn kiểm tra cam kết cuối cùng của mình hoặc cam kết cuối cùng của đồng nghiệp hoặc cam kết hợp nhất. Nếu bạn muốn tránh nó và nếu bạn muốn đặt cam kết của mình sau cam kết của đồng nghiệp, bạn có thể rebasethay thế merge. Bạn có thể làm điều đó với một trong hai git commit && git rebasehoặc git pull --rebase.
Arnaud Denoyelle

Cảm ơn vì mẹo, @Arnaud. Sau khi đọc nhiều câu hỏi SO khác nhau, nhận xét này đã làm được. Tùy chọn ưu tiên của tôi khi đồng nghiệp đang làm việc trên các tệp khác nhau là git pullsau khi sắp xếp các thay đổi của tôi, vì tôi thấy đó là điều tự nhiên nhất. Mặc dù tôi nhận thấy nhiều quy trình công việc khác nhau hoạt động (lưu trữ cũng tốt), vì vậy nó có thể là vấn đề của sở thích.
nephewtom

51

Tôi khuyên bạn nên kéo từ nhánh từ xa thường xuyên nhất có thể để giảm thiểu các hợp nhất lớn và xung đột có thể xảy ra.

Đã nói rằng, tôi sẽ đi với lựa chọn đầu tiên:

git add foo.js
git commit foo.js -m "commit"
git pull
git push

Cam kết các thay đổi của bạn trước khi kéo để các cam kết của bạn được hợp nhất với các thay đổi từ xa trong quá trình kéo. Điều này có thể dẫn đến xung đột mà bạn có thể bắt đầu giải quyết khi biết rằng mã của bạn đã được cam kết nếu có bất kỳ điều gì xảy ra và bạn phải hủy hợp nhất vì bất kỳ lý do gì.

Tuy nhiên, tôi chắc chắn rằng ai đó sẽ không đồng ý với tôi, tôi không nghĩ rằng có bất kỳ cách chính xác nào để thực hiện quy trình hợp nhất này, chỉ những gì phù hợp nhất với mọi người.


1
Bạn có thể vui lòng xem cập nhật của tôi cho câu hỏi không? Tôi đã quên giải thích những gì for git addđược sử dụng chính xác trong ví dụ của tôi.
Màu xanh lá cây

1
Không tạo ra bất kỳ sự khác biệt nào cho dù đó là tệp mới hay tệp được theo dõi / sửa đổi. Vẫn cam kết và sau đó kéo.
Jasarien

7

Tôi nghĩ git pull --rebaselà cách sạch nhất để đặt các cam kết cục bộ gần đây của bạn lên trên các cam kết từ xa mà bạn không có ở một số điểm nhất định.

Vì vậy, bằng cách này, bạn không phải kéo mỗi khi bạn muốn bắt đầu thực hiện thay đổi.


Đây là những gì tôi cũng làm, nhưng chỉ để chỉ ra rằng chắc chắn có hai trường phái suy nghĩ chính về vấn đề này (tập trung vào việc liệu tốt nhất là khắc phục xung đột giữa các cam kết cá nhân hay một lần trong cam kết hợp nhất) với chính Linus trong trại hợp nhất . Rất may, bản thân công cụ này không có ý kiến, vì vậy hãy sử dụng nó theo cách nào phù hợp nhất với bạn và nhu cầu dự án của bạn :-)
Luke Usherwood

3

Bạn muốn thay đổi của mình nằm trên trạng thái hiện tại của chi nhánh từ xa. Vì vậy, có lẽ bạn muốn kéo ngay trước khi bạn tự cam kết. Sau đó, hãy đẩy lại các thay đổi của bạn.

Tệp cục bộ "bẩn" không phải là vấn đề miễn là không có bất kỳ xung đột nào với nhánh từ xa. Tuy nhiên, nếu có xung đột, quá trình hợp nhất sẽ không thành công, vì vậy không có rủi ro hoặc nguy hiểm trong việc kéo trước khi thực hiện các thay đổi cục bộ.


1
Như Arnaud đã đề cập sẽ không hiệu quả, việc kéo đòi hỏi bạn phải thực hiện các thay đổi của mình trước.
Jasarien

Git của tôi có vẻ rất vui khi có nhiều thay đổi cục bộ. Tất nhiên, nếu các tệp giống nhau được thay đổi trên nhánh từ xa, phần hợp nhất của kéo không thành công. Để tạo ra một xung đột hợp nhất thích hợp, trước tiên tôi phải cam kết. Vì vậy, nếu tập hợp các tệp được thay đổi cục bộ và từ xa là rời rạc, kéo và sau đó nhấn là tốt. Nếu không, git sẽ không kéo. Không có thiệt hại được thực hiện bằng cách thử.
AlexE,

Đây là tùy chọn ưa thích của tôi khi mọi người đang làm việc trên các tệp khác nhau và tôi thấy nó là tự nhiên nhất.
cháu trai
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.