Làm việc với Git trên nhiều máy


15

Điều này nghe có vẻ hơi lạ, nhưng tôi đang tự hỏi về một cách tốt để làm việc trong Git từ nhiều máy được nối với nhau theo một cách nào đó. Có vẻ như tôi có hai lựa chọn và tôi có thể thấy lợi ích từ cả hai phía:

  • Sử dụng git chính nó để chia sẻ, mỗi máy có repo riêng và bạn phải tìm nạp giữa chúng.
    • Bạn có thể làm việc trên một trong hai máy ngay cả khi máy kia đang ngoại tuyến. Điều này tự nó là khá lớn tôi nghĩ.
  • Sử dụng một repo được chia sẻ qua mạng giữa các máy.
    • Không cần phải thực hiện thao tác kéo git mỗi khi bạn chuyển đổi máy, vì mã của bạn luôn được cập nhật.
    • Không bao giờ lo lắng rằng bạn đã quên đẩy mã từ máy không lưu trữ khác, hiện không thể truy cập được, vì bạn đang làm việc với một tập tin trên máy này.

Trực giác của tôi nói rằng mọi người thường đi với lựa chọn đầu tiên. Nhưng nhược điểm tôi thấy là không phải lúc nào bạn cũng có thể truy cập mã từ các máy khác của mình và tôi chắc chắn không muốn đẩy tất cả các chi nhánh WIP của mình lên github vào cuối mỗi ngày. Tôi cũng không muốn phải rời khỏi máy tính của mình mọi lúc để tôi có thể lấy trực tiếp từ chúng. Cuối cùng, một điểm nhỏ là tất cả các lệnh git để giữ cho nhiều nhánh được cập nhật có thể trở nên tẻ nhạt.

Có xử lý thứ ba về tình huống này? Có lẽ một số công cụ của bên thứ ba có sẵn giúp quá trình này dễ dàng hơn? Nếu bạn đối phó với tình huống này thường xuyên, bạn đề nghị gì?


git là một công cụ tạo phiên bản phi tập trung và git luôn tạo một bản sao cục bộ của repo của bạn khi nhân bản, khái niệm về kho lưu trữ "tập trung" hoặc "duy nhất" đơn giản là không tồn tại trong thế giới của git theo thuật ngữ toàn cầu.
dùng827992

2
@ user827992 Tôi hoàn toàn nhận thức được 100% về thực tế đó. Tôi không nghĩ rằng tôi đã đề nghị bất cứ điều gì về tập trung. Điều duy nhất tôi đã đề cập là nếu bạn đang sử dụng một tập tin, một máy là máy chủ lưu trữ, theo nghĩa là nó lưu trữ các tập tin một cách vật lý. Đó là một khái niệm hoàn toàn ngoài dvcs.
Tesserex

chủ đề stackoverflow.com/questions/1550378/ này chứa một số suy nghĩ tốt. Cam kết, đẩy, kéo, đặt lại và xóa chi nhánh là một trong số đó (có thể là tự động)
phil294

Câu trả lời:


14

Tôi đối phó với cả hai giải pháp đề xuất của bạn hàng ngày. Có hai khái niệm chính để xử lý chúng tốt.

  1. Sử dụng các nhánh chủ đề. Tôi tin rằng lịch sử sản xuất nên còn nguyên sơ. Kết quả là tôi dành rất nhiều thời gian để làm cho productionlịch sử của chi nhánh của tôi hợp lý, có thể nhân rộng và có thể sửa lỗi. Tuy nhiên, khi sử dụng nhiều máy, đôi khi bạn cần phải tiến hành công việc. Sử dụng một nhánh chủ đề. Bạn có thể pullpushchi nhánh này từ cả hai máy với ít nỗ lực và khi nó sẵn sàng hợp nhất vào masterhoặc khởi động production lại nó để tạo ra một lịch sử dễ bảo trì hơn.
  2. Sử dụng một repo được chia sẻ qua mạng là tốt, trừ khi bạn cũng chia sẻ nó với những người dùng khác. Chúng tôi sử dụng một kho lưu trữ được chia sẻ cho các tập lệnh, được đặt tên một cách sáng tạo là scriptskho lưu trữ. Lúc đầu, nó có vẻ là một ý tưởng tốt vì repo không thay đổi thường xuyên, nhưng theo thời gian, nó trở thành một cơn ác mộng. Thật dễ dàng để ghi đè lên công việc của nhau và cuối cùng bạn sẽ dành nhiều thời gian kiểm soát lưu lượng không khí khi triển khai kho lưu trữ khi bạn làm việc trong đó.

Giải pháp tốt nhất là giữ một kho lưu trữ cục bộ trên mỗi máy và chia sẻ các nhánh chủ đề giữa chúng thông qua một điều khiển từ xa. Cam kết làm việc theo tiến độ cho các chi nhánh như bạn muốn. Miễn là bạn sẵn sàng đưa rebasehọ vào một lịch sử dễ hiểu hơn, nó khá hiệu quả trong thực tế.

Nếu bạn thấy mình làm việc trên nhiều nhánh chủ đề trong suốt cả ngày nhưng không muốn đẩy từng cái riêng lẻ vào điều khiển từ xa, git push <remote>thì theo mặc định sẽ đẩy tất cả các nhánh phù hợp sang <remote>. Điều này mặc định sẽ thay đổi trong một phiên bản sau này của git , nhưng có thể gạt bởi thiết push.defaulttrong một file cấu hình hoặc bằng cách xác định phù hợp refspec:

git push <remote> :

3

Nếu không phải tất cả các máy đều hoạt động liên tục, sẽ không có viên đạn bạc: trước khi tắt máy, bạn phải đẩy các thay đổi sang một nơi khác. Tôi đẩy đến một máy chủ riêng, nhưng nó cũng có thể là dropbox hoặc chìa khóa usb bạn mang theo mọi nơi.

Đúng, đẩy nhiều chi nhánh đến một vị trí trung tâm có thể trở nên tẻ nhạt, nhưng điều đó không quá khó để viết kịch bản. Tôi sử dụng một push.shtập lệnh cho cái đó, cái mà tôi chạy mỗi khi tôi làm việc trên máy.


2

Tôi đã đến đây từ một hướng hơi khác (và tôi sử dụng đồng bóng, nhưng về mặt triết học thì giống nhau). Đây không phải là ý tưởng của tôi, tôi chỉ sử dụng nó và nó hoạt động cho các công cụ cá nhân của tôi.

Tôi đã tạo một bản sao các kho lưu trữ của mình trong thư mục SkyDrive (nó có thể là dropbox hoặc một công cụ đồng bộ hóa ma thuật khác mà bạn chọn), sau đó tôi đã cấu hình các phiên bản trên hai máy của mình để tự động đẩy vào kho lưu trữ SkyDrive theo cam kết.

Khi tôi chuyển đổi các hộp thì đó chỉ là vấn đề kéo và cập nhật - theo lý thuyết bạn sẽ luôn làm việc theo kiểu tuyến tính mặc dù trong nhiều kho lưu trữ.

Chìa khóa ở đây là repo SkyDrive tồn tại chủ yếu để cung cấp một phương tiện để đảm bảo rằng tôi đã truy cập được ít nhiều phiên bản mã mới nhất trên cả hai máy của mình - mặc dù nó sẽ hoạt động tốt hơn - và để cung cấp một sao lưu thêm. Bất cứ điều gì "được thực hiện" đều được đẩy lên Kiln (nếu tôi đang sử dụng git và tôi hiểu chính xác cách chơi trò chơi thì đó sẽ là điểm mà tôi thực hiện một cuộc nổi loạn).

Điều tôi thực sự không muốn làm là chạy một thư mục dùng chung ... nếu bạn đang sử dụng DVCS thì bạn cũng có thể tận hưởng lợi ích này.


0

Đầu tiên trong hai lựa chọn của bạn là câu trả lời. Điều đó ngụ ý bởi "D" trong "DVCS". Mỗi người dùng có kho lưu trữ cục bộ của riêng họ và các kho lưu trữ nói chuyện với nhau theo cách có thể quản lý được.

Bạn có thể thực hiện thay thế thứ hai, nhưng vấn đề là, chỉ có một thư mục làm việc của kho lưu trữ. Vì vậy, cây công việc có thể chỉ ở một trạng thái tại một thời điểm - không có Joe làm việc trên một chi nhánh và Jane làm việc trên một chi nhánh khác. Vì vậy, các nhà phát triển có thể ghi đè lên các thay đổi của nhau, xử lý công việc của nhau. Tại sao, nó giống như không có kiểm soát phiên bản nào cả!

Có một nền tảng trung gian được gọi là, có một kho lưu trữ trống trên một ổ đĩa mạng và có những người dùng cá nhân đăng ký và thoát khỏi nó. Điều này tách biệt công việc WIP của bạn (có, bạn giữ cục bộ) khỏi công việc bạn xuất bản cho đến kho lưu trữ. Nó không "tiết kiệm" lên - đó là "xuất bản". Công việc bạn muốn đồng nghiệp của bạn nhìn thấy và sử dụng.

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.