Là một nhà phát triển duy nhất (hiện tại), tôi nên sử dụng Git như thế nào? [đóng cửa]


60

Tôi có nhiều dự án trên Git mà cuối cùng tôi muốn đưa người khác vào. Tuy nhiên, ngay bây giờ chỉ có tôi và tôi sử dụng Git và GitHub rất đơn giản: không có chi nhánh và về cơ bản chỉ sử dụng các xác nhận như một bản sao lưu cho các tệp cục bộ của tôi. Đôi khi tôi sẽ quay lại và xem các phiên bản trước của các tệp của mình để tham khảo, nhưng tôi không cần phải thực hiện bất kỳ sự quay trở lại nào cho đến thời điểm này, mặc dù tôi đánh giá cao tùy chọn mà tôi cần trong tương lai.

Là một nhà phát triển duy nhất, những tính năng Git hoặc GitHub nào tôi có thể tận dụng có thể mang lại lợi ích cho tôi ngay bây giờ? Quy trình làm việc của tôi nên như thế nào?

Ngoài ra, có bất kỳ thực tiễn cụ thể nào mà tôi cần bắt đầu thực hiện trong dự đoán sẽ thêm người khác vào các dự án của mình trong tương lai không?


3
Như những người khác đã giải thích, Git cung cấp cho bạn rất nhiều sức mạnh. Là một nhà phát triển duy nhất, điều quan trọng mà bạn sẽ đánh giá cao sau này là nếu cung cấp cho bạn một bản ghi về những thay đổi bạn đã thực hiện (nhóm các thay đổi trong một số tệp thành một bộ), khi bạn thực hiện chúng và tại sao! Đó cũng là cách luyện tập tuyệt vời khi bạn trở thành thành viên của một đội.
Dẫn đầu Geek

1
Đóng cửa vì thú vị. :)

@ user93458 như mọi khi! Các chủ đề đóng thường chính xác là những gì tôi đang tìm kiếm.
Miroslav Popov

câu hỏi tuyệt vời mà không bao giờ nên được đóng lại.
tập một

Câu trả lời:


64

Ngoài ra, có bất kỳ thực tiễn cụ thể nào mà tôi cần bắt đầu thực hiện trong dự đoán sẽ thêm người khác vào các dự án của mình trong tương lai không?

Tất nhiên. Có một cách thực hành tốt đơn giản mà bạn có thể sử dụng ngay cả khi bạn không có nhóm ngay bây giờ: tạo một nhánh riêng để phát triển. Ý tưởng là nhánh chính sẽ chỉ chứa các phiên bản mã được phát hành hoặc các thay đổi lớn. Điều này có thể được chấp nhận dễ dàng bởi các nhà phát triển mới tham gia dự án của bạn.

Bên cạnh đó, phân nhánh rất hữu ích ngay cả khi bạn đang làm việc một mình. Chẳng hạn, bạn tìm thấy một lỗi trong khi đang trong quá trình mã hóa một tính năng mới. Nếu bạn không sử dụng các nhánh, bạn sẽ phải thực hiện cả hai: thêm các tính năng mới và sửa lỗi trong cùng một nhánh. Điều này không tốt: P Mặt khác, nếu bạn đã tạo một nhánh mới để tạo tính năng mới của mình, bạn có thể kiểm tra nhánh phát triển, sửa lỗi và kiểm tra lại nhánh tính năng mới.

Đây chỉ là một ví dụ ngắn gọn về những gì bạn có thể làm là một lập trình viên duy nhất. Tôi chắc chắn phải có nhiều thực hành tốt.

Tôi đánh giá cao bài viết này: Một mô hình phân nhánh Git thành công


+1 - Điều đó có ý nghĩa. Tôi cũng sẽ xem xét kỹ hơn về bài viết đó, nó có vẻ rất hữu ích.
VirtuosiMedia

Tôi không phải là chuyên gia về git, chủ yếu là người dùng Mercurial. Liệu lời khuyên chi nhánh dev này vẫn giữ trong trường hợp của Mercurial? Có vẻ như nó làm nhưng có thể một số khác biệt làm cho nó không phải là một ý tưởng tốt trong trường hợp này?
Klaim

2
Vâng, nó giữ khá nhiều cho tất cả các kiểm soát nguồn. Tôi thực sự làm điều đó ngược với SVN; thân cây "chính" là dành cho sự phát triển mới nhất, diễn ra hàng ngày hoặc thậm chí thường xuyên hơn. Khi một bản phát hành được yêu cầu, mã được đóng băng và cắt một nhánh. Chi nhánh đó chỉ nhận được các bản cập nhật nhỏ để khắc phục các sự cố phát hành chính, và sau đó bản phân phối được tạo từ đó. Bằng cách đó, tôi có một nhánh mã nguồn đằng sau mỗi phiên bản được phát hành. Điều này tốt hơn là chỉ đơn giản là gắn thẻ hoặc gắn nhãn b / c nếu các cam kết xuất hiện sau nhãn nhưng trước khi phát hành, bạn không biết liệu chúng có thực sự bị loại trừ hay không.
KeithS

+1 cho bài viết; @Klaim - yup, hoạt động rất tốt cho hg. thực sự nên được gọi là "mô hình phân nhánh DCVS thành công"
Wyatt Barnett

+1 cảm ơn vì liên kết, nó đã thay đổi cách tôi sẽ làm việc với git, không phải do bạn bận tâm mà như họ nói, từng chút giúp đỡ!
Newtopian

14

Tôi chính xác trong tình huống này nhưng tôi đã chọn một quy trình phức tạp hơn một chút mặc dù không nhất thiết phải phức tạp hơn với Git.

Mục tiêu lúc đầu là học cách git nên tôi đã thực hiện một số khám phá. sau đó trở lại khá nhiều quy trình công việc bạn mô tả.

Sau một thời gian, điều này trở nên khó khăn khi làm việc với một số tình huống phát sinh, nó cũng mang lại cho tôi những thói quen xấu khó có thể phá vỡ khi tôi gia nhập một đội.

Vì vậy, tôi giải quyết cho những điều sau đây:

  • Kho lưu trữ cục bộ để làm việc.
  • Master nhánh như một thân cây ổn định cho ứng dụng
  • Một nhánh cho mỗi tính năng / cấu trúc lại, về cơ bản là một nhánh cho mỗi thay đổi khá lớn sẽ được thực hiện.
  • Hợp nhất trở lại thân cây khi nhánh ổn định và tất cả các bài kiểm tra vượt qua.

Tôi cũng thiết lập một tài khoản trung tâm git nơi tôi đồng bộ hóa trung kế. Điều này cho phép tôi dễ dàng bắt đầu làm việc trên các máy tính khác nhau. Đó là do sự cần thiết nhưng cho phép tôi tìm thấy các lỗi liên quan đến môi trường mà tôi không có trên các máy tính khác. Vì vậy, bây giờ tôi tạo thói quen thử một dự án trên một hệ thống "trinh tiết" khác ít nhất một lần. Tiết kiệm cho tôi rất nhiều đau đầu khi đến lúc phải triển khai cho khách hàng.

  • Tôi gắn thẻ mọi phiên bản làm cho nó vào github như một phiên bản đáng tin cậy.
  • Nếu được phát hành cho khách hàng, tôi sẽ phân nhánh từ phiên bản này để tạo một thân cây ổn định thứ hai để sửa lỗi do khách hàng khai báo.

Nhiều chi nhánh lúc đầu có vẻ như quá mức cần thiết nhưng nó THỰC SỰ giúp ích rất nhiều. Tôi có thể bắt đầu một ý tưởng trong một chi nhánh, làm việc với nó trong một thời gian và khi tôi bắt đầu chạy vòng tròn, tôi đã từ bỏ và bắt đầu một chi nhánh khác để làm việc khác. Sau đó, một ý tưởng xuất hiện nơi tôi sẽ trở lại nhánh nướng và khám phá ý tưởng này. tổng thể này làm cho tôi RẤT năng suất hơn vì tôi có thể hành động chớp nhoáng và ý tưởng rất nhanh và xem nó có hiệu quả không. Chi phí chuyển đổi chi nhánh với GIT cực kỳ thấp khiến tôi rất nhanh nhẹn với cơ sở mã của mình. Điều đó nói rằng tôi vẫn phải nắm vững khái niệm rebase để làm sạch lịch sử của mình nhưng vì tôi chỉ có một mình nên tôi nghi ngờ tôi thực sự cần phải làm vậy. Đẩy nó là "tốt để học".

Khi tất cả các nhánh trở nên phức tạp thì tôi đã khám phá tùy chọn nhật ký để vẽ một cây thay đổi và xem nhánh nào ở đâu.

Câu chuyện dài, git không giống SVN, CVS hay (brrr) TFS. Sự phân nhánh rất rẻ và phạm sai lầm sẽ xóa sạch công việc thực sự khá khó khăn. Chỉ một lần tôi mất một số công việc và đó là vì tôi đã thực hiện các cam kết của mình quá lớn (xem các thói quen xấu ở trên). Nếu bạn cam kết thường xuyên, bởi những khối nhỏ, git chắc chắn sẽ là đồng minh tốt nhất của bạn.

Đối với tôi, git đã mở mang đầu óc tôi về việc kiểm soát nguồn thực sự là gì. Bất cứ điều gì khác trước đây chỉ là cố gắng để có được nó, git là người đầu tiên, mà trong tâm trí của tôi, đã có nó. Điều đó nói rằng, tôi đã không thử DVCS khác, rất có thể tuyên bố này có thể được mở rộng cho cả gia đình.

Một lời khuyên cuối cùng, dòng lệnh là bạn của bạn. Không phải nói rằng các công cụ đồ họa là không tốt, hoàn toàn ngược lại nhưng tôi thực sự đã mò mẫm git khi tôi rơi xuống dòng lệnh và tự mình thử nó. Nó thực sự được thực hiện rất tốt, dễ làm theo với một hệ thống trợ giúp rất toàn diện. Vấn đề lớn nhất của tôi là bị trói vào bàn điều khiển xấu xí trong cửa sổ cho đến khi tôi tìm thấy giải pháp thay thế.

Bây giờ tôi sử dụng cả hai, tích hợp Eclipse với Git để xem những gì đang diễn ra trong thời gian thực và thực hiện một số thao tác như tìm khác biệt, khám phá lịch sử cho một tệp, v.v. Và dòng lệnh để phân nhánh, hợp nhất, đẩy, lấy và các cây nhật ký phức tạp hơn . một số kịch bản cơ bản và tôi chưa bao giờ làm việc hiệu quả liên quan đến kiểm soát nguồn và tôi chưa bao giờ có quá nhiều quyền kiểm soát đối với nguồn của mình.

Chúc may mắn, hy vọng điều này sẽ giúp.


4

Tôi thành thạo một số mô hình phân nhánh tinh vi và sử dụng một số trong công việc. Tuy nhiên, khi tôi làm việc một mình trong các dự án, tôi làm khá nhiều chính xác những gì bạn đang làm bây giờ. Tôi luôn có thể tạo một nhánh sau thực tế nếu tôi cần, nhưng tôi gần như không bao giờ làm. Làm việc một mình, tôi hiếm khi có các sửa lỗi không thể đợi cho đến khi nhiệm vụ hiện tại của tôi kết thúc. Lời khuyên của tôi là hãy làm quen với một số mô hình phân nhánh, nhưng không có ý nghĩa phức tạp cho đến khi bạn cần.


4

Đối với một mô hình đơn giản hơn, bạn có thể nhìn vào những gì GitHub làm. "Dòng chảy GitHub" rất đơn giản và có một hướng dẫn tuyệt vời tại đây: https://guides.github.com/int sinhtion / stream / index.html

Tóm tắt (từ blog của Scott Chacon ):

Vậy, GitHub Flow là gì?

  • Bất cứ điều gì trong nhánh chính đều có thể triển khai
  • Để làm việc trên một cái gì đó mới, hãy tạo một nhánh được đặt tên mô tả của master (ví dụ: new-oauth2-scopes)
  • Cam kết với chi nhánh đó tại địa phương và thường xuyên đẩy công việc của bạn đến cùng chi nhánh có tên trên máy chủ
  • Khi bạn cần phản hồi hoặc trợ giúp hoặc bạn nghĩ chi nhánh đã sẵn sàng để hợp nhất, hãy mở một yêu cầu kéo
  • Sau khi người khác đã xem xét và đăng xuất trên tính năng, bạn có thể hợp nhất nó thành chủ
  • Khi nó được hợp nhất và được đẩy thành 'master', bạn có thể và nên triển khai ngay lập tức
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.