Tôi có nên mong đợi nhóm của mình có nhiều hơn một trình độ cơ bản với hệ thống kiểm soát nguồn của chúng tôi không?

Công ty của tôi đã chuyển từ Subversion sang Git khoảng ba tháng trước. Chúng tôi đã có nhiều tuần thông báo trước khi chuyển đổi. Vì tôi chưa bao giờ sử dụng Git trước đây (hoặc bất kỳ DVCS nào khác), tôi đã đọc Pro Git và dành một ít thời gian để lưu trữ các kho lưu trữ của riêng mình và chơi xung quanh, để khi chúng tôi chuyển đổi, tôi có thể tiếp tục làm việc với nỗi đau tối thiểu. Bây giờ tôi là 'Git guys' theo mặc định.

Với một vài ngoại lệ, hầu hết nhóm của tôi vẫn không biết Git hoạt động như thế nào. Ví dụ, họ vẫn nghĩ các nhánh là bản sao hoàn chỉnh của mã nguồn và thậm chí còn đi xa đến mức sao chép repo vào nhiều thư mục (mỗi thư mục một nhánh). Họ thường nhìn vào Git như một hộp đen đáng sợ.

Do tính chất cơ bản của kiểm soát nguồn trong công việc hàng ngày của chúng tôi (không đề cập đến lượng sức mạnh vô lý mà Git dành cho chúng tôi), tôi cho rằng bất kỳ nhà phát triển nào không đạt được mức độ thành thạo nhất định với nó là trách nhiệm pháp lý .

Tôi có nên hy vọng nhóm của mình có ít nhất một số hiểu biết về cách Git hoạt động nội bộ và cách sử dụng nó ngoài các hoạt động kéo / hợp nhất / đẩy cơ bản nhất không? Hay tôi chỉ đang làm một cái gì đó từ không có gì?

Sự chuyên nghiệp đương nhiên sẽ ra lệnh rằng một nhà phát triển trở nên quen thuộc với các công cụ tiêu chuẩn của nhóm của họ, ngay cả khi họ là người mới và không quen thuộc (hoặc thậm chí không mong muốn).

Tuy nhiên, một vài điều trong bài viết của bạn cho tôi tạm dừng.

Chúng tôi đã có nhiều tuần thông báo trước khi chuyển đổi.

Tuần nào? Trao đổi kiểm soát nguồn là một vấn đề lớn. Đáng lẽ phải có nhiều tháng thông báo dẫn đến một sự thay đổi như thế.

Với một vài ngoại lệ, hầu hết nhóm của tôi vẫn không biết Git hoạt động như thế nào.

Vì vậy, công ty của bạn chuyển sang một hệ thống kiểm soát nguồn mà ít ai, nếu có, hiểu vào thời điểm đó?

Trừ khi có một số bối cảnh khác, có vẻ như toàn bộ động thái đã không được nghĩ ra (di chuyển, không phải là sự lựa chọn - Tôi là một người hâm mộ cuồng nhiệt).

Chúng tôi đã giới thiệu Git nơi tôi làm việc và đương nhiên có sự phản kháng. Đó là cho một dự án mới vì vậy chúng tôi hiện đang duy trì hai kho lưu trữ.

Một phần của vấn đề là mọi người sẽ không thấy được lợi ích của việc chuyển sang SCM khác khi người mà họ đang sử dụng làm việc cho họ. Nó giúp ích khi chúng tôi ngồi lại với nhóm của chúng tôi trong một vài buổi, trong đó chúng tôi sẽ chỉ hiển thị các trường hợp sử dụng từ các dự án của chúng tôi và cách Git làm cho nó dễ dàng hơn. Ví dụ: những điều đã giúp chúng tôi:

• Chi nhánh địa phương để khuyến khích thử nghiệm
• Git bisect để dễ dàng theo dõi lỗi
• cam kết thường xuyên mà không làm gián đoạn người khác
• Chuyển đổi nhanh giữa các chi nhánh

v.v ... Mỗi người trong số họ đã giải quyết một vấn đề mà chúng tôi đã gặp phải với SCM trước đây và vì vậy mọi người có thể đánh giá cao Git hơn.

Một điều khác là bạn không thể mong đợi mọi người đi ra ngoài và đọc sách về nó bởi vì rất ít ý chí. Có lẽ họ cần phải hoàn thành công việc, có trách nhiệm khác hoặc bất kỳ lý do nào.

Vì vậy, là 'chuyên gia Git', bạn phải ngồi xuống và làm cho mọi người sử dụng nó dễ dàng nhất có thể. Họ muốn được viết mã, không gây rối với hệ thống SCM của họ.

CLI của Git là những vấn đề khó hiểu và tầm thường (đối với bạn và tôi) sẽ ngăn mọi người làm việc. Đây là những gì đã xảy ra trong nhóm của chúng tôi (nhớ rằng, đây là những nhà phát triển khá có năng lực):

• Git với SSH trên Windows là một vấn đề phổ biến.
• Mọi người sẽ kéo, hợp nhất, nhưng không đẩy hợp nhất. Vì vậy, biểu đồ sẽ là một mớ hỗn độn lớn
• Vấn đề về hiệu năng trên Windows khiến "trạng thái git" mất 15 giây
• Không thể tìm ra làm thế nào để kéo một chi nhánh mới. Họ sẽ thực hiện một "kiểm tra git -b", chi nhánh của bất cứ điều gì họ đang làm
• EGit trong nhật thực có một thực đơn áp đảo. Cuối cùng đã nói với mọi người sử dụng dòng lệnh lúc đầu
• Dựa trên mục trước đó, hợp nhất và thiết lập git mergetool
• Nhầm lẫn về sự khác biệt giữa "git add" và "git commit" và "git đẩy".

Chúng tôi vẫn nhận được một số kháng cự nhưng mọi người chắc chắn có thể thấy những lợi ích. Điều quan trọng là có một vài người Git để được hướng dẫn và sẵn sàng giúp đỡ. Ngoài ra tôi sẽ tránh dạy những thứ hay ho như reset / rebase / - sửa đổi / v.v. bởi vì hầu hết mọi người sẽ sử dụng Git như SVN, tốt hơn là để họ khám phá nó nếu họ mong muốn.

Thành thạo so với Git-mania

Một thuật ngữ như thành thạo cơ bản có thể có nghĩa là những điều khác nhau cho những người khác nhau. Rất nhiều người dường như có git-mania (không có gì sai với điều đó). Nhiều người trong chúng ta đã bị thiêu rụi thực sự bởi sự cẩu thả của chính mình và của người khác với sự kiểm soát nguồn.

Tại sao nó có vấn đề (rất nhiều)

Các công cụ kiểm soát nguồn rất quan trọng vì việc sử dụng sai có thể làm chậm không chỉ một người, mà cả một nhóm. Việc lạm dụng Git sẽ ít gây ra vấn đề hơn so với việc lạm dụng SVN, CVS và các hệ thống khác. Trong lịch sử, việc sử dụng các hệ thống khóa các tệp bị khóa đặc biệt có vấn đề và các công ty đã thuê các nhóm xây dựng riêng biệt để khi ai đó gặp rắc rối, có một chuyên gia thông thạo hầu như không làm gì ngoài kiểm soát nguồn có thể chữa vết thương cho kho lưu trữ. Điều này một phần giải thích một số niềm đam mê bạn tìm thấy đằng sau git.

Trình độ cơ bản trông như thế nào?

Một số tiêu chí cụ thể bao gồm:

• Không có tài liệu tham khảo:

  • Có thể thêm tệp, cam kết thay đổi, đẩy và kéo cập nhật.
  • Có thể xem trạng thái và hoạt động sửa đổi.
  • Có thể phân nhánh và hợp nhất nhanh chóng và không có lỗi giới thiệu.
  • Có thể sử dụng kiểm tra phù hợp.
  • Tạo các bình luận cam kết đáp ứng các tiêu chí của nhóm để bình luận.
  • Khác biệt thay đổi giữa bản sao làm việc và lưu trữ.

• Với tài liệu:

  • Thêm người dùng và thông tin đăng nhập cho repo địa phương.
  • init một repo địa phương.
  • Quản lý repo từ xa.
  • Định cấu hình các tệp bị bỏ qua, tạo cặp khóa công khai / riêng tư PKI.
  • Di chuyển và xóa các tập tin.
  • Sử dụng bisect để tìm thay đổi đã giới thiệu một lỗi cụ thể.

Một mô hình tinh thần vững chắc của git và mã được quản lý là rất quan trọng để tránh sai lầm.

Bạn sẽ thêm gì cho trình độ / chuyên môn nâng cao?

Sử dụng thành thạo là điều cần thiết cho các nhà phát triển và có thể một số thành viên khác trong nhóm của bạn. Các công cụ như Git là chi phí hoạt động và nên được học ở mức độ có thể gần như tự động. Giảm thiểu thời gian và mất tập trung được tạo ra bằng cách sử dụng các lệnh git được lặp lại hàng ngàn lần mỗi năm có giá trị cao.

Sẽ luôn có một số thành viên trong nhóm của bạn là những người sử dụng năng lượng và sử dụng hầu hết mọi lệnh với hầu hết mọi tùy chọn. Đề nghị của tôi là các thành viên trong nhóm được khuyến khích tiếp tục học git (và các công cụ khác) cho đến khi ROI cho việc học giảm xuống dưới giá trị của việc làm một cái gì đó khác trong dự án, với giới hạn chính là bắt kịp với các mục đã được ghi từ hiện tại tăng tốc.

GIT là một công cụ duy nhất để thực hiện một công việc và một trong những vấn đề lớn nhất của nó là nhiều nhà truyền giáo GIT mong muốn tất cả người dùng GIT trở thành những chuyên gia về nắp ca-pô hiểu được những điểm tốt nhất về cách thức hoạt động của nó. Đây là điểm yếu lớn nhất của GIT - để sử dụng nó, bạn cần biết nó hoạt động như thế nào. Không có công thức nấu ăn với GIT, bạn dự kiến ​​sẽ là một chuyên gia GIT hoặc không sử dụng nó. Thật tuyệt khi bạn đọc Pro-GIT, tổ chức của bạn cần một bậc thầy GIT "goto" (hoặc hai) để tối đa hóa khoản đầu tư vào nó, bởi vì không phải nhà phát triển nào cũng muốn trở thành một GIT Guru - và điều đó cũng ổn.

Nhóm cần biết cách sử dụng GIT (Thực tế họ chỉ cần biết cách sử dụng các phần của GIT mà quy trình công việc yêu cầu họ sử dụng), chứ không phải cách GIT hoạt động. Thật bất lợi khi mong đợi mọi nhà phát triển biết mọi chi tiết về mọi công cụ họ sử dụng. Nếu bạn chưa có sách công thức hỗ trợ quy trình làm việc của mình, bạn chưa triển khai GIT, bạn đã đổ nó cho các nhà phát triển.

Tôi không cho khỉ cách GIT hoạt động, miễn là tôi biết cách làm cho git hoạt động với tôi.

Đúng.

Cho dù "công ty" đã quyết định sử dụng công cụ nào, nhóm phát triển của bạn nên dành thời gian học cách sử dụng công cụ này đúng cách. Không có gì làm tổn thương năng suất hơn một loạt các nhà phát triển sợ hoặc không biết gì về một công cụ. Nếu họ đang sử dụng sai hoặc làm việc chống lại nó, các vấn đề sẽ nảy sinh và khi đến với anh chàng, bạn sẽ được giao nhiệm vụ dọn dẹp mớ hỗn độn.

Git là một quá trình chuyển đổi khó khăn đối với nhiều người, vì vậy một buổi tập huấn bắt buộc có thể theo thứ tự. Điều này sẽ giúp giải quyết rất nhiều vấn đề mà mọi người đang gặp phải.

Tôi chỉ sử dụng Git trong môi trường cá nhân chứ không phải chuyên nghiệp và trong khi tôi thích sức mạnh của nó và ý tưởng về kiểm soát nguồn phi tập trung hơn, nó có vấn đề lớn. Git có sự trừu tượng bị rò rỉ và phải mất nhiều lệnh để thực hiện những điều đơn giản (ví dụ để thực hiện thay đổi: git add, git commit, sau đó git đẩy). Ngoài ra, một số tài liệu còn thiếu và / hoặc khó hiểu như với mô tả lệnh rebase ... "Cam kết cục bộ cổng chuyển tiếp đến đầu dòng được cập nhật". Tôi không biết điều đó có nghĩa là gì, và mặc dù bây giờ tôi biết bạn có thể di chuyển cam kết và viết lại lịch sử với nó (một phiền toái khác ... tại sao bạn lại được phép làm điều này ???) Tôi sẽ không bao giờ đoán được điều đó từ lệnh đó sự miêu tả. Tôi nghĩ rằng một số đọc về một phần của nhóm của bạn, và một số đào tạo thêm do bạn cung cấp là theo thứ tự.

Đào tạo và hiểu biết là những yêu cầu tối thiểu. Một người chịu trách nhiệm nên đảm bảo rằng có một kế hoạch về cách nhóm của bạn sẽ sử dụng nó. Bạn sẽ không chấp nhận một ngôn ngữ lập trình mới mà không có hướng dẫn. Đào tạo lái xe hiệu quả hơn nhiều khi các quy tắc thiết lập đường được kết hợp.

Không; Tôi nghĩ thật hợp lý khi mong đợi những điều sau:

1. Làm các công việc hàng ngày (cam kết, đẩy, kéo, rẽ nhánh, hợp nhất, chia đôi, v.v.) mà không cần cầm tay.
2. Làm các công việc không thường xuyên mà không cần hướng dẫn lặp đi lặp lại. (Một vài lần lặp lại là ok - Tôi phải gặp ai đó 2-3 lần trước khi tên của họ thực sự dính vào.)

Nếu họ không thể làm số 1, thì phần đào tạo của bạn sẽ không đủ. Nếu họ không thể làm số 2, thì trước tiên hãy đảm bảo bạn giải thích mọi thứ rõ ràng trước khi quá buồn.