Bối cảnh

Nhóm 8 kỹ sư của tôi hiện đang chuyển sang Git (từ Subversion) cho điều lớn lao tiếp theo của chúng tôi. Chúng tôi có một số ít các kỹ sư 'có kinh nghiệm hơn' đang gặp khó khăn trong việc nhận Git. Tôi được hỏi những câu hỏi tầm thường tương tự mặc dù đã cung cấp hướng dẫn sử dụng, các hoạt động đào tạo và các phiên bảng trắng. Chúng tôi đã có hai chuyên gia tư vấn Junior, người đã chọn mọi thứ trong vài ngày và nó thực sự đã làm sáng tỏ vấn đề này. Đây không phải là một mẫu được giới hạn ở Git nhưng kết quả là nó sẽ hiển thị.

Câu hỏi

Tôi không cảm thấy đặc biệt có lợi cho các kỹ sư không thể / không học - đặc biệt là đội ngũ nhân viên có trình độ thâm niên chúng tôi có ở đây. Tuy nhiên, tôi muốn nhóm thành công và xây dựng một sản phẩm tuyệt vời. Chúng tôi đang sử dụng mô hình Git Flow tập trung và tôi cảm thấy như tất cả các thuật ngữ mới đang gây trở ngại cho họ.

Có điều gì tôi có thể làm để giúp những nhân viên này học Git không?

Sourcetree là khách hàng đang được sử dụng bởi cả nhóm.

Cung cấp cho họ một món đồ chơi.

Git thật khó. Đặc biệt là nếu bạn đã thực hiện kiểm soát nguồn trong một mô hình khác. Tôi đã phá vỡ bản dựng lần đầu tiên khi tôi cố gắng làm việc với git. Nó khiến tôi hoang tưởng đến mức tôi không muốn đăng ký cho đến khi mọi thứ hoàn tất. Tôi đã ẩn phiên bản trong các thư mục. Sau đó tôi cuối cùng đã tìm ra những gì tôi cần để vượt qua nó:

Tôi cần một nơi an toàn để chơi.

Khi tôi đã có được điều đó, tôi đã cố tình gây ra vấn đề để tôi có thể học cách khắc phục tất cả chúng ở nơi an toàn. Tôi đã phát triển một mô hình mà tôi có thể sử dụng ngay cả khi bị gián đoạn và vẫn trở lại trạng thái tốt. Không lâu sau, mọi người đã đến nhờ tôi giúp đỡ với git. Tất cả chỉ vì tôi dành thời gian để chơi với một món đồ chơi.

Nếu bạn chỉ cần ném chúng vào vực sâu, bạn sẽ may mắn nếu chúng nổi lên.

Các nhà phát triển trung bình không cần nhiều quà tặng của git. Đó là một hệ thống kiểm soát nguồn phân tán nhưng hầu hết các đội sẽ sử dụng nó với một repo chính tắc trung tâm để đẩy và kéo từ đó.

Các lệnh cốt lõi mà nhóm của bạn sẽ cần là:

• kéo và hợp nhất các thay đổi từ xa và xử lý các xung đột (có khả năng nổi loạn)
• cam kết và đẩy cam kết vào điều khiển từ xa (hoặc đẩy để dàn dựng repo / chi nhánh để đưa các thay đổi vào chính sau khi xem xét)
• Để được hỗ trợ: sửa chữa lộn xộn sau khi làm điều gì đó sai.

những thứ mà người dùng cao cấp hơn sẽ cần là

• xử lý các cam kết địa phương
• quản lý chi nhánh

Đối với những người không quen thuộc với git và những người không muốn tìm hiểu, hãy thiết lập một vài lệnh bí danh nhanh để thực hiện chúng và đảm bảo rằng mọi thứ đều chính xác (thêm tệp mới, xóa tệp đã xóa khỏi repo, v.v.)

Hãy chắc chắn rằng đây là những tài liệu tốt và bằng chứng ngu ngốc.

Điều này nằm trong mạch của truyện tranh xkcd , chỉ cần ghi nhớ các lệnh và hy vọng mọi thứ không bị rối quá nhiều, khi họ yêu cầu một chuyên gia.

Cho họ sử dụng UI Git.

Nếu họ có kinh nghiệm với TortoiseSVN, thì TortoiseGit (chỉ dành cho Windows) hoạt động gần như chính xác. Mặt khác, SourceTree (Windows + Mac) thật tuyệt vời - chúng tôi có nhiều QA không phải là nhà phát triển, những người có thể dễ dàng làm chủ các tác vụ phức tạp trong Git nhờ SourceTree.

Câu trả lời này cố gắng giải quyết làm thế nào để khiến các lập trình viên cao cấp quan tâm git, chứ không phải về cách học gitnhanh nhất - vì điều đó, cuốn sách git xuất sắc là tuyệt vời, hoặc bất kỳ số lượng hướng dẫn nào (=> Google). Liên kết tốt để đi với câu trả lời này là Git là một cấu trúc dữ liệu hoàn toàn chức năng hoặc đặc biệt là cách ngắn git lưu trữ dữ liệu của bạn .

Tôi sợ rằng tôi có một cái nhìn khá ảm đạm về điều này. Tôi đã ở chính xác đôi giày của bạn - Tôi là một gitmọt sách và muốn biến đổi một đội từ đó svn, hãy đối mặt với nó, kết quả rất nhỏ. Trong trường hợp của tôi, điều đó đã dẫn đến việc tôi chủ động thay đổi nhận thức của chính mình và chấp nhận rằng mọi người, chỉ là không thể "buộc phải hạnh phúc". Con người không phải là máy tính, thật khó để lập trình chúng. Tôi vẫn hạnh phúc vì đã cố gắng, nó đã cho tôi thấy một cách khá mềm mỏng những gì tôi làm và những gì tôi không muốn làm trong cuộc sống chuyên nghiệp của mình.

Có những người bắt đầu có động lực khi những thứ mới được tham gia, và có những người bị mất điều kiện. Điều này không liên quan gì git, nhưng gitcụ thể là bạn luôn có tác dụng "tại sao chúng ta nên sử dụng nó nếu svnnó vẫn ổn?", Đó là một rào cản tâm lý lớn.

Ngoài ra, thực sự mò mẫm gitđòi hỏi một sự quan tâm mạnh mẽ trong các cấu trúc dữ liệu trừu tượng. Nghe có vẻ khó tin, nhưng theo kinh nghiệm của tôi, có những lập trình viên không có hứng thú với điều đó và họ cảm thấy buồn chán và quá tải bởi các yếu tố phức tạp hơn các mảng đơn giản. Bạn có thể tranh luận qua lại xem liệu những người đó có nên làm công việc họ đang làm không, nhưng đó là những gì nó được.

Nếu mọi người không quan tâm đến nó, họ sẽ không hiểu nó. Đơn giản và đơn giản. Tôi cá rằng sự không quan tâm là lý do chính của điểm kém ở trường, không thiếu trí thông minh.

Điều đó nói rằng, đây sẽ là một chương trình giảng dạy như tôi sẽ áp dụng nó, dựa trên sự tích lũy kiến ​​thức từ dưới lên trên. Nó không làm việc cho tôi, nhưng bạn có thể lấy nó làm nguồn cảm hứng để tự mình lăn lộn.

GUI

Mặc dù cách tiếp cận sau đây không nhất thiết cần hỗ trợ GUI cho các hành động ( git addtrong kho lưu trữ thế giới xin chào ...), nhưng nó giúp ích rất nhiều để có GUI để trực quan hóa kho lưu trữ, ngay từ đầu. Nếu bạn không thể quyết định sử dụng cái nào, thì hãy dùng gitknhư là phương sách cuối cùng. Nếu kẻ của bạn sử dụng bất kỳ loại trình soạn thảo trực quan nào, hãy tìm gitthành phần GUI của họ .

Cấu trúc dữ liệu (tĩnh) là chính

Bắt đầu bằng cách giải thích các loại dữ liệu nội bộ (chỉ có ba cộng một trong số chúng: đốm, cây, cam kết, thẻ chú thích, cuối cùng không có gì đáng lo ngại ở giai đoạn này) và cấu trúc của chúng. Bạn có thể dễ dàng làm điều đó trên bảng trắng / bằng bút chì; Cây rất dễ vẽ vì nó không bao giờ có thể thay đổi, bạn có thể chỉ cần thêm công cụ mọi lúc. Bạn có thể thực hiện một phiên chơi trong kho lưu trữ cục bộ mới được tạo và sử dụng git cat-fileđể xem xét các đối tượng thực tế để cho họ thấy rằng thực tế chúng là tầm thường như quảng cáo.

Nếu bạn có thể giúp họ hiểu rằng

• ... thực sự chỉ có 3 loại đối tượng trong lịch sử, tất cả chúng đều rất đơn giản, gần như tầm thường và
• ... hầu hết các gittiểu ban chỉ "xoa bóp" các đối tượng đó bằng cách này hay cách khác, với các hoạt động gần như tầm thường (về cơ bản, chỉ có một: thêm một cam kết mới ở đâu đó) và ...
• ... mọi thứ có thể dễ dàng được nhìn thấy ngay trước mặt bạn lsvà git cat-file...

sau đó họ sẽ có bản dịch tinh thần về những gì thực sự có trong kho lưu trữ. Tại thời điểm này, các seniours có thể nhớ rằng phần bên trong của svnma thuật phức tạp (từng có vấn đề với các khóa bên trong kho svn, hoặc với các nhánh "tái hòa nhập" và như vậy?), Và điều này có thể thúc đẩy họ một chút.

Một vấn đề, cụ thể với mọi người đã từng svn, là làm quen với ý tưởng rằng một cam kết (đối tượng, không phải hành động) luôn là toàn bộ cây thư mục. Trong svn, mọi người được sử dụng để cam kết các tập tin cá nhân. Đó là một cách tiếp cận hoàn toàn khác nhau. Ồ, và thực tế là cùng một thuật ngữ "cam kết" được sử dụng cho cả một đối tượng tĩnh và một hành động cũng không giúp được gì.

Vấn đề khác đối với các svnchàng trai là svnsử dụng lịch sử tuyến tính chứ không phải cây. Đây là, một lần nữa, rất khác nhau. Vì vậy, đây là thời điểm để chỉ ra những khác biệt này rất nhiều .

Hành động giải thích về mặt cấu trúc

Khi họ đã hiểu những phần mà một gitkho lưu trữ được tạo ra, đó là lúc để cho họ thấy chính xác những gì các tiểu ban riêng lẻ gitlàm về những phần đó.

Tôi đang nói về add, commitkết hợp với thư mục làm việc cục bộ và giai đoạn (đảm bảo rằng họ hiểu rằng thư mục làm việc không giống với khu vực tổ chức không giống với kho lưu trữ).

Khi họ đã hiểu rằng các lệnh này chỉ đơn giản là trồng cây (trong đó, một lần nữa, ở giai đoạn này, bao gồm 3 loại - đốm, cây, cam kết, không chỉ cam kết), bạn có thể thực hiện trước git pushvà git pull(ở chế độ chuyển tiếp nhanh! ) để hiển thị cho họ theo gitnghĩa đen chỉ đẩy các đối tượng của nó xung quanh, rằng băm thực sự chỉ là băm nội dung, mà bạn có thể dễ dàng sao chép nội dung này xung quanh bằng lệnh sao chép hệ thống tệp, v.v.

Rõ ràng, tránh xa bất kỳ tùy chọn không quan trọng nào của các lệnh đó, chúng ta đang nói git add hello.txtở đây.

Chi nhánh

Lưu ý rằng việc phân nhánh đặc biệt khó khăn với svnmọi người, vì nó hoàn toàn khác nhau. Các svnmô hình là nhiều dễ dàng hơn để hình dung, như có về cơ bản là không có gì để hình dung - đó là theo quan điểm của đồng bằng. Các gitmô hình không quá nhiều. Hãy chắc chắn rằng họ nhận thức được ngay từ đầu rằng các nhánh và thẻ chỉ là "ghi chú dán" chỉ ở đâu đó và không thực sự "tồn tại" theo lịch sử tĩnh, bất biến.

Sau đó làm ví dụ sau ví dụ dễ dàng để hiển thị những gì bạn thực sự có thể làm với họ. Khi bản thân bạn dường như đã quen git, bạn sẽ không gặp khó khăn trong việc tìm kiếm động lực ở đó. Hãy chắc chắn rằng họ luôn xem điều này theo cách cây phát triển.

Nếu họ có điều đó, bạn có thể giải thích git pullnó thực sự như thế nào git fetch && git merge; làm thế nào tất cả các kho lưu trữ thực sự chứa chính xác cùng một đối tượng ( git fetchgần giống như sao chép nội dung scpbên trong thư mục đối tượng git), v.v.

Có lẽ, nếu đến lúc này bạn chưa đạt được để đánh thức sự quan tâm của họ, thì bạn cũng có thể từ bỏ, nhưng nếu họ có thể đi xa hơn, thì họ có tất cả các công cụ tinh thần theo ý của họ, và sẽ có rất ít sợ liên quan nữa. Phần còn lại (git workflow ...) nên xuống dốc sau đó.

Những từ cuối

Điều này nghe có vẻ như rất nhiều nỗ lực, và nó thực sự là. Đừng bán cái này dưới dạng "chúng tôi cần cái này cho dự án này" nhưng "điều này giúp cá nhân bạn phát triển và sẽ giúp bạn trong tất cả các tương tác tiếp theo của bạn". Bạn cần rất nhiều thời gian cho việc này, và thời gian là tiền bạc. Nếu bạn không có sự chấp nhận của ban quản lý về điều này, điều đó có thể không có giá trị; bạn có thể nên nói chuyện với sếp của bạn.

Nếu bạn quyết định bạn muốn từ bỏ giảng dạy phát triển những người dường như không có khả năng nắm bắt nó, nhưng bạn hoàn toàn phải sử dụng gittrong tương lai, xem xét thay thế tất cả các tương tác với gitcác lệnh bằng script nấu-up hoặc một số giao diện mà mất tất cả gitchi tiết cụ thể đi. Đổ tất cả các kiểm soát lỗi, vv trong các kịch bản, và cố gắng để làm việc đó.

Tôi muốn giới thiệu bạn đến mục blog này của Joel Spolsky .

Lý do bạn thấy cho các nhà phát triển cơ sở này chọn nó một cách nhanh chóng rất có thể là vì họ không có một khái niệm định trước về cách kiểm soát phiên bản nói chung hoạt động, hoặc ít nhất không phải là một mô hình tinh thần ăn sâu vào nó. Vì vậy, họ đi vào với một bảng đá sạch. Các lập trình viên cao cấp hơn của bạn có khả năng đang cố gắng áp dụng các khái niệm mà họ đã biết và thất bại do điều đó.

Thêm vào đó, nhiều như tôi không muốn nói; Ai thực sự đọc hướng dẫn sử dụng? Thông thường họ rất tệ trong việc giải thích sử dụng cơ bản. Chỉ cần nhìn vào trang cam kết git từ hướng dẫn và xem xét có bao nhiêu thuật ngữ và cụm từ mới được giới thiệu cho một người không theo kịp khái niệm này. Nếu không có phần giới thiệu tốt, có khả năng tôi đã từ bỏ việc sử dụng Git ngay tại đó và sau đó.

Lời khuyên cá nhân của tôi sẽ là bắt đầu giải thích các lệnh:

• thêm git <tập tin>
• cam kết
• kéo git
• đẩy git
• tình trạng git

Hợp lý hợp lý các xung đột sẽ được giải thích tiếp theo, bởi vì đó chắc chắn sẽ là vấn đề đầu tiên của bạn một khi mọi người học cách cam kết mã.

Thông thường, các tình huống sẽ xuất hiện khi mọi người sẽ cần đầu tư nhiều thời gian hơn vào việc học (hoàn nguyên, gắn thẻ, hợp nhất xung đột, chi nhánh, nổi loạn, móc nối) nhưng cố gắng giải thích tất cả những điều này trước khi cần thiết sẽ không giúp những người gặp khó khăn khi vào dòng chảy.

Chỉ để gói lại: Từ kinh nghiệm cá nhân của tôi, một số người đơn giản là không dành nhiều thời gian để khám phá các kỹ thuật, khái niệm hoặc công cụ mới và họ thường có xu hướng chọn những thứ bạn giới thiệu với tốc độ chậm hơn. Điều này không có nghĩa là họ là những lập trình viên tồi hoặc người xấu, nhưng họ thường có bộ kỹ năng hẹp hơn.

Git là một suy nghĩ lại nếu bạn đã học cách kiểm soát nguồn trên SVN. Nhiều thói quen bạn đã phát triển ở đó (có thể là cách thực hành tốt nhất cho SVN) sẽ khiến bạn hiểu lầm khi sử dụng git. Điều này chủ yếu là do mô hình phân nhánh của git rất khác nhau về cơ bản. Nó không tận dụng các thư mục cho các nhánh và cũng có thể làm cho nó không tuyến tính vì nó được thiết kế để hỗ trợ các trường hợp sử dụng phân tán tốt hơn. Phải mất một thời gian để quên đi những thói quen SVN và hiểu làm thế nào bạn đang phải sử dụng git.

Bắt đầu đơn giản

Bạn nói rằng bạn đã chọn Gitflow làm tiêu chuẩn của mình để quản lý chi nhánh. Điều này đánh tôi là sai lầm lớn nhất của bạn.

Để trích dẫn Gitflow được coi là có hại :

Tất cả các nhánh được sử dụng này buộc GitFlow phải có một bộ quy tắc phức tạp phức tạp mô tả cách chúng tương tác. Các quy tắc này, cùng với lịch sử vô hình, khiến việc sử dụng GitFlow hàng ngày trở nên rất khó khăn đối với các nhà phát triển.

Bạn có thể đoán điều gì xảy ra bất cứ khi nào bạn thiết lập một mạng lưới các quy tắc phức tạp như thế không? Điều đó đúng - mọi người mắc lỗi và phá vỡ chúng một cách tình cờ. Trong trường hợp của GitFlow, điều này xảy ra mọi lúc. Dưới đây là một danh sách ngắn, không có nghĩa là đầy đủ các lỗi ngớ ngẩn phổ biến nhất mà tôi đã quan sát. Những điều này được lặp đi lặp lại liên tục, đôi khi mỗi ngày, thường xuyên lặp đi lặp lại bởi cùng một nhà phát triển - những người, trong hầu hết các trường hợp, rất có năng lực trong các lĩnh vực phần mềm khác.

Các nhà phát triển của bạn có thể bị choáng ngợp bởi sự phức tạp tuyệt đối của tiêu chuẩn này. Cá nhân tôi không nghĩ rằng nó có bất kỳ lợi ích nào, và bài viết trên đây cũng đưa ra lập luận tương tự. Nhưng đó là một cuộc thảo luận riêng biệt. Tuy nhiên, về mặt khách quan, đó là một tiêu chuẩn khá nặng với nhiều quản lý thủ công và nó đòi hỏi rất nhiều nỗ lực nhận thức.

Bạn cần bắt đầu đơn giản hơn. Đừng lo lắng về một tiêu chuẩn phân nhánh ngay bây giờ. Tập trung vào làm quen với việc sử dụng git trước. Bạn chỉ thực sự cần một vài thao tác để bắt đầu:

• nhân bản
• kéo
• chi nhánh
• Hợp nhất
• cam kết
• đẩy
• kiến thức về cách làm .gitignoreviệc
• có thể gắn thẻ

Vâng, ban đầu lịch sử của bạn có thể nhìn vào một chút lộn xộn. Không sao đâu Đừng lo lắng về nó ngay bây giờ. Chỉ cần có được chúng bằng cách sử dụng git .

Tăng dần kiến ​​thức

Từ đây, bạn có thể dần dần giáo dục họ về cách sử dụng nâng cao hơn một chút.

• Dạy cho họ lệnh stash sử thi
• Dạy họ cách sử dụng thiết lập lại khi họ muốn vứt bỏ cam kết cục bộ mà họ vừa thực hiện
• Dạy họ cách sửa đổi
• Dạy chúng cách rebase để tránh các cam kết không cần thiết
• Dạy chúng cách phản ứng tương tác để tổ chức các cam kết trước khi chúng thúc đẩy
• Dạy họ cách họ có thể thanh toán từ bất kỳ hàm băm, thẻ hoặc chi nhánh nào

Đặc biệt đảm bảo rằng bạn tận dụng các cơ hội để chỉ cho họ những cách sạch hơn để nhận mã của họ vào kho lưu trữ, nhưng cũng dạy công cụ này trong các hoạt động đào tạo và những gì có bạn. Có một hoặc hai bậc thầy mà mọi người có thể tiếp cận khi họ không chắc chắn những việc cần làm cũng sẽ giúp ích rất nhiều. Nếu bạn có một cái gì đó như Slack, hãy tạo một kênh chuyên dụng và khuyến khích mọi người hỏi và trả lời các câu hỏi ở đó.

Sau đó chọn một tiêu chuẩn phân nhánh

Một khi bạn có hầu hết các công ty có thẩm quyền sử dụng git, thì bạn có thể xem xét các tiêu chuẩn phân nhánh. Chọn một mặt trước là một ý tưởng thực sự tồi tệ vì nhiều lý do:

• Họ không có đủ kiến ​​thức về công cụ để cho bạn biết liệu tiêu chuẩn có hoạt động tốt cho các trường hợp sử dụng của công ty không
• Họ sẽ không thể đưa ra các tiêu chuẩn thay thế
• Họ phải học cả công cụ và tiêu chuẩn cùng một lúc
• Một số người sẽ cho rằng tiêu chuẩn bạn chọn là cách duy nhất họ có thể sử dụng git
• Họ sẽ không thể xác định các trường hợp cạnh hiếm gặp trong đó tiêu chuẩn gây hại nhiều hơn là tốt

Bạn không nên bàn giao một luồng công việc Git từ trên núi. Nhóm của bạn cần có đầu vào cho nó và có thể cung cấp cho bạn thông tin phản hồi về việc nó có tốt hay không. Họ không thể làm điều này nếu họ thậm chí không hiểu các nguyên tắc cơ bản. Bạn không cần mỗi nhà phát triển duy nhất có kiến ​​thức sâu rộng như thế này, nhưng bạn chắc chắn cần một vài người thực sự có được nó. Và bạn cần đại đa số ít nhất là có năng lực trong git để họ biết đủ để ở lại trên đường ray.

Dưới đây là một vài lựa chọn thay thế cho Gitflow mà nhóm của bạn có thể xem xét:

• Một lần
• Quy trình làm việc chi nhánh
• Quy trình làm việc tập trung

Nhìn vào chúng và Gitflow, cân nhắc chúng với các trường hợp sử dụng của bạn và chọn một cái phù hợp.

Tôi thấy stackoverflow rất hữu ích trong lần đầu tiên tôi chọn thuật ngữ Git. Những câu hỏi như thế này thực sự hữu ích cho tôi (chủ yếu là vì sự đồng nhất của chúng) và tôi đã giữ chúng mở trong các tab trong vài tuần đầu tiên tôi sử dụng nó. Có thể in ra một vài câu trả lời in đậm? Đặc biệt là sơ đồ trên cái đầu tiên.

Sự khác biệt giữa cam kết git cam và phạm git đẩy phạm vi là gì?

Sự khác biệt giữa 'git pull' và 'git fetch' là gì?

Tôi cũng tìm thấy một đại diện trực quan của thân cây là hữu ích đáng kinh ngạc nhưng bạn đã bao gồm cái đó với SourceTree.

_{Ngoài ra, bit này có thể thuộc về một bình luận nhưng tôi thiếu người đại diện: Tôi là một trong những chuyên gia tư vấn cơ sở được đề cập trong câu hỏi. Trước khi tôi bắt đầu, tôi đã có một số ý tưởng về hệ thống kiểm soát nguồn là gì và tôi đã chọc SVN theo nghĩa đen hai lần, Gusdor cho tôi nhiều tín dụng hơn tôi xứng đáng. Toàn đội đã được đào tạo Git chuyên dụng chất lượng cao, đồ chơi và thời gian để chơi. Vấn đề không nằm ở hướng dẫn của Gusdor. Tôi hy vọng có một giải pháp thay thế tốt cho vấn đề này để tôi có thể đánh dấu nó một cách chăm chỉ và tìm hiểu thêm.}

Mua cho họ một cuốn sách

Thành thật mà nói, tôi đã rơi thẳng vào trại bạn mô tả. Tôi đến từ một nền tảng của SourceSafe và ClearCase. Lúc đầu, Git hoàn toàn khó hiểu với tôi, mặc dù ông chủ của tôi đã đi qua nó vài lần.

Điều giúp tôi là một cuốn sách mô tả rõ ràng những gì đang diễn ra, nhưng quan trọng hơn, Git khác biệt cơ bản như thế nào so với bất kỳ hệ thống kiểm soát nguồn nào mà tôi đã sử dụng trước đây. Bây giờ, tôi thích Git hơn bất kỳ sự lựa chọn nào khác.

Thật không may, tôi không thể nhớ lại cuốn sách nào tôi đã đọc vào thời điểm đó, nhưng, chỉ cần đảm bảo rằng bất kỳ cuốn sách nào bạn nhận được cho họ (hoặc chỉ cho họ) tập trung vào sự khác biệt của nó và cách nó đòi hỏi một tâm trí khác.

Dự đoán tốt nhất cho một đề nghị cuốn sách là:

Pro Git của Scott Chacon (liên kết Amazon để dễ dàng ... mua từ bất cứ ai bạn muốn: https://www.amazon.com/dp/1484200772/ref=cm_sw_r_cp_dp_T1_BNruzbBQ8G9A6 )

Lưu ý : Bạn không mua một cuốn sách tham khảo cho Git. Điều đó sẽ không giúp được gì cả.

Từ kinh nghiệm của tôi, một số người có thể thoải mái sử dụng git mà không hiểu nó. Họ tìm thấy hướng dẫn cơ bản, nhận các lệnh cơ bản và chúng là tốt để đi. Đó có lẽ là nơi mà các chuyên gia tư vấn cơ sở phù hợp với nó. Tôi không tin rằng bạn thực sự có thể học git trong vài ngày!

Những người khác, không thể làm điều đó, họ cần hiểu git đang làm gì và điều đó cần nhiều thời gian hơn. Tôi đã ở trong thể loại đó; Tôi thấy nó thực sự hữu ích khi chơi với nội dung của .gitthư mục, đó là khi mọi thứ bắt đầu nhấp cho tôi. Ngoài ra một trong một phiên với lãnh đạo công nghệ của chúng tôi đã giúp.

Bạn có thể thực hiện một hướng dẫn bởi vì mọi người học khác nhau và có thể thực sự bối rối về các phần khác nhau, trong một phần trên một phiên sẽ dễ dàng hơn để xem và giải quyết. Nếu họ thực sự bị làm phiền bởi thực tế là họ không hiểu cách git theo dõi các chi nhánh, hãy hiển thị cho họ nội dung của .gitthư mục, v.v.

Tôi đang giới thiệu về việc giới thiệu gittôi đang ở đâu (từ TFS) vì vậy câu hỏi của bạn là kịp thời với tôi, đặc biệt là khi tôi cũng bị đẩy lùi khi chuốt đối tượng.

Trong Peopleware , các luận điểm cơ bản của toàn bộ cuốn sách là:

Các vấn đề chính của công việc của chúng tôi không có nhiều công nghệ như xã hội học trong tự nhiên .

Tôi đưa ra điều này bởi vì chúng ta không phải là một vấn đề kỹ thuật. git, trong khi hơi khó hiểu, có lẽ không vượt quá khả năng của bạn hoặc các nhà phát triển cấp cao của tôi, trừ khi họ cực kỳ ngu ngốc *.

Chúng ta hãy nhìn nó từ quan điểm nhà phát triển của bạn, như mọi người, không phải máy móc kỹ thuật:

Bạn đang yêu cầu họ ngừng sử dụng một hệ thống kiểm soát nguồn mà họ (có khả năng) làm chủ, với hệ thống mà họ không làm được. Nó giống như yêu cầu một gitchuyên gia ngừng sử dụng gitvà chuyển sang svnkhông? Tôi cho rằng chuyên gia git sẽ khó chịu, và có lẽ không nỗ lực nhiều svnvì githoạt động tốt và có những phần mà cô ấy thực sự thích mà thực sự khó thực hiện svn.

Đó có lẽ là lý do tại sao các đàn em đã làm điều đó tốt hơn - có lẽ họ không nắm bắt được svnvà đó gitlà cơ hội để họ từ bỏ nó ^.

Mặc dù vậy, người cao niên cảnh giác với chi phí cơ hội - nếu họ học git, thì họ không:

• Học React / Angular / Swift / Blockchain / Kotlin (một số điều khác mà họ cảm thấy nên học).
• Làm DIY / whittling / sail / thơ / glockenspiel / bất cứ điều gì khác mà họ thực sự muốn làm.
• Dành thời gian với con cái / người thân / bạn bè / những người quan trọng khác.

• Cung cấp "điều mới lớn" này - có thời hạn, ngân sách, v.v ... Có lẽ họ lo lắng về điều đó.

  "Tôi cần phải làm tất cả những điều trên, tại sao tôi phải sử dụng git khi chúng tôi đã kiểm soát nguồn?"

Những lý do nào khiến bạn đưa ra cho họ để chuyển từ một thứ mà họ giỏi, sang một thứ khác thực sự khó xử khi bạn chưa quen với nó, và đòi hỏi phải suy nghĩ lại về cách bạn làm dev? Bạn đã giải thích lợi ích của các gittính năng?

Yêu cầu kéo? Checkins hạt mịn? Nguồn phân phối? Nĩa?

Họ đã đưa vào những lý do này? Đây là những thay đổi lớn, về cấu trúc nếu bạn đang ở trong một bộ óc kiểm soát nguồn tập trung - không chỉ thay đổi kỹ thuật mà cả văn hóa, và chúng tôi biết việc thay đổi văn hóa khó khăn như thế nào.

Vì vậy, về cơ bản, hãy suy nghĩ về những gì bạn đang yêu cầu các nhà phát triển của mình làm và đảm bảo rằng đó là lý do chính đáng. Nếu bạn chỉ muốn làm điều đó bởi vì svnngu ngốc và cũ kỹ và không ai sử dụng nữa thì tốt, nhưng điều đó khó bán hơn cho những người không nghĩ như bạn và chỉ muốn tiếp tục với ngày của họ. Bạn cần nêu các lợi ích theo nghĩa có ý nghĩa với nhóm của bạn và cho dự án. Nếu bạn có thể khiến họ đồng ý rằng điều đó gitđáng để chịu đựng, thì bạn không phải lo lắng về việc họ học công nghệ, chỉ cần đồng ý với bất kỳ quy trình công việc nào bạn đã thiết lập.

Chúc may mắn.

Tôi nghĩ rằng đây không phải là một câu hỏi kỹ thuật phần mềm và nhiều hơn một câu hỏi tâm lý. Tôi muốn tham khảo Algorithms to Live By: The Computer Science of Humand Decisions. Trong đó tác giả đi sâu vào chủ đề của sự đánh đổi / khai thác. Con người thường trải qua giai đoạn thăm dò và sau đó qua giai đoạn khai thác (sử dụng) những gì họ đã khám phá. Có một số lý thuyết toán học vững chắc đằng sau lý do tại sao đây là trường hợp để có được sử dụng tối ưu từ một cái gì đó trong một khoảng thời gian nhất định.

Điều này cũng mở rộng đến tuổi và kinh nghiệm. Con người coi cuộc sống của chính họ như một khoảng thời gian, và sau một giai đoạn thăm dò nhất định, việc bắt đầu sử dụng kiến ​​thức của bạn là tối ưu. Họ trích dẫn một nghiên cứu trong đó những người tham gia lớn tuổi được hỏi liệu họ có muốn gặp một người nổi tiếng mà họ thích hay đúng hơn là một thành viên trong gia đình. Họ thường chọn thành viên trong gia đình, trong khi những người trẻ tuổi chọn người nổi tiếng hơn. Tuy nhiên, khi được yêu cầu tưởng tượng họ sẽ quyết định thế nào nếu họ trẻ hơn 20 tuổi, người già thường xuyên chọn người nổi tiếng. Điều đó cho thấy rằng mọi người ngừng xây dựng mạng xã hội của họ khi họ tin rằng họ có ít sự khám phá hơn là khai thác những gì họ đã biết.

Các kỹ sư cao cấp của bạn có lẽ đã lớn tuổi, họ có thể đã trải qua một vài hệ thống kiểm soát phiên bản. SVNcó lẽ là hệ thống tốt nhất mà họ đã sử dụng cho đến bây giờ (ít nhất là nhìn vào các hệ thống phiên bản cũ hơn mà tôi đã sử dụng, SVN đã đánh bại tất cả).

Chiến lược tối ưu của họ là khai thác SVN, vì họ đã thực hiện hành trình khám phá và nhận thấy đây là điều tốt nhất, hiện tại họ khai thác.

Đây là tâm lý cơ bản của con người và hàng trăm ngàn năm tối ưu hóa tiến hóa mà bạn đang chiến đấu chống lại.

Bạn sẽ cần cho họ thấy a) họ có một sự nghiệp trước mặt họ bao lâu, để khiến họ suy nghĩ từ một góc nhìn khác về khoảng thời gian họ thấy và b) hỏi họ xem họ nghĩ gì tuyệt vời và những gì họ ' lại mất tích SVN. Bạn có thể đưa ra hàng trăm lợi ích git, nhưng họ sẽ có một ý tưởng rõ ràng tại sao SVNlà tốt nhất, sau tất cả những gì họ đã trải nghiệm có lẽ là 5 hệ thống kiểm soát phiên bản trước đây. Bạn cần tìm ra những vết nứt trong bộ giáp của cuộc tranh luận đó, và sau đó xem liệu gitcó thể giải quyết những vấn đề này không, thì họ sẽ tự thuyết phục mình.

Đừng cung cấp cho họ một công cụ hoặc GUI để sử dụng Git. Nó sẽ chỉ gây nhầm lẫn mọi thứ. Git được hình thành để chạy trên một dòng lệnh vì vậy đó có lẽ là nơi nó được học. Bất kỳ GUI nào cũng có thể đi kèm với các điều khoản và đặc thù riêng của nó, gắn với những gì đơn giản.

Tiếp theo sẽ là xem xét một số vấn đề mà Git làm tốt hơn SVN. Để khiến nhóm của bạn học nó, bạn cần thúc đẩy họ xem tại sao git lại tốt hơn.

• Khả năng cam kết trong khi không kết nối với mạng
• Khả năng làm và chơi với các chi nhánh của riêng họ
• Các bản vá có thể được gửi giữa nhau và vẫn hợp nhất theo dõi
• hái anh đào mà không đau.
• nổi loạn thay đổi
• tìm lỗi với mối nối git

Tôi chắc rằng SVN đã chuyển sang trong vài năm qua, nhưng những thứ đó từng là những thứ sẽ gây ra một thế giới đau khổ. Nếu các nhà phát triển thấy rằng công cụ mới này không chỉ là một thứ lạ mắt mà còn có những lợi thế vững chắc cho công việc của họ, họ có thể có nhiều khả năng nhận được đằng sau nó.

Đó là một điều mới để tìm hiểu và có đủ những điểm tương đồng mà nó có thể gây nhầm lẫn, nhưng thực sự trong năm 2017 DCVS có khá nhiều kỹ năng cần thiết cho mọi nhà phát triển.

Nói họ đừng lo lắng

Trong Git, một khi công việc được cam kết, gần như không thể mất. Công việc duy nhất bạn có thể dễ dàng mất là công việc chưa được cam kết.

Chỉ cho họ cách làm git reflogviệc. Họ không phải biết cách sử dụng nó; họ chỉ cần biết nó ở đó, vì vậy họ có thể nhận được sự giúp đỡ để lấy lại công việc nếu có sự cố xảy ra.

Sau đó, gây ấn tượng với họ quy tắc đơn giản này: Khi nghi ngờ, hãy cam kết. Họ luôn có thể sao lưu cam kết sau này (thậm chí từ điều khiển từ xa!).

Không sử dụng GUI

GUI sẽ giúp họ bắt đầu nhanh hơn, nhưng họ sẽ không bao giờ thực sự hiểu Git. Hơn nữa, tôi đã phát hiện ra rằng nó không "gần như không thể mất" công việc đã cam kết khi sử dụng một giao diện Git. Tôi đã thấy GUI làm những điều khủng khiếp như đưa ra một danh sách kiểm tra khi hợp nhất và sau đó, nếu người dùng bỏ chọn một mục, xóa sạch tệp đó khỏi lịch sử mà không có cảnh báo và không có bản ghi nào về nó. Một GUI tệ hơn nhiều so với việc học Git dòng lệnh.

Mã chương trình cặp cam kết

Học git add -Atheo sau git commitkhông nên quá khó, nhưng đặc biệt khi hợp nhất (hoặc nổi loạn) với điều khiển từ xa, họ sẽ cần một số trợ giúp. Làm rõ rằng bất cứ ai cũng được chào đón để yêu cầu hỗ trợ bất cứ lúc nào. Đứng trong khi họ gõ các lệnh và ghi chú. Theo thời gian, họ sẽ tăng dần số lượng tình huống mà họ có thể xử lý mà không cần trợ giúp.

Git đã an toàn

Một số người ở trên đã nói về việc có "một nơi an toàn để chơi." Nhưng Git là nơi an toàn. Chỉ có hai trường hợp bình thường, hàng ngày dễ bị mất việc:

• Mã không cam kết
• Sử dụng GUI

Hãy chắc chắn rằng họ cam kết sớm và thường xuyên, và họ không bắt đầu đi sai đường với GUI và họ sẽ sớm thấy rằng họ có thể tin tưởng Git với mã của họ thậm chí nhiều hơn các hệ thống kiểm soát nguồn khác trong quá khứ.

Tôi sẽ khuyên một cái nhìn tại Gitless . Đó là một trình bao bọc trên git đơn giản hóa rất nhiều quy trình công việc cơ bản (không cần phải lo lắng về khu vực tổ chức, các chi nhánh giữ các bản sao làm việc của riêng chúng, việc sử dụng đơn giản hơn git rebaseđược xử lý gl fuse, v.v.) trong khi duy trì kho lưu trữ git bên dưới để cộng tác hoặc nếu bạn cần làm điều gì đó bất thường. Ngoài ra, các tin nhắn thân thiện hơn một chút. Và các lệnh đủ gần để git hoạt động như một bước đệm nếu họ cần sử dụng một hệ thống mà không cần thiết cho nó vì bất kỳ lý do gì.

Tôi đã thử ghi lại những điều cơ bản về cách sử dụng dòng lệnh của git. Nó vẫn còn khó hiểu - cả với bản thân tôi (người có kinh nghiệm sử dụng Perforce và Source Safe) và cho các lập trình viên ưa thích mô hình "chỉ cần nén các thư mục liên quan" cũ. Thật đáng lo ngại khi có một công cụ mờ đục sửa đổi nội dung của thư mục làm việc của tôi và thường phải tranh luận với công cụ này để kết hợp các thay đổi cụ thể vào thư mục làm việc của tôi.

Thay vào đó, tôi sử dụng hai loại gián tiếp.

• Tôi sử dụng GitKraken để cung cấp lịch sử trực quan của các chi nhánh của tôi và GUI ẩn các câu lệnh dòng lệnh. GitKraken xử lý các tương tác giữa kho lưu trữ từ xa "gốc" và git nghĩ là thư mục làm việc cục bộ của tôi.

• Tôi cũng giữ một thư mục làm việc cục bộ "thực" tách biệt với thư mục git nghĩ là thư mục làm việc cục bộ của tôi. Tôi đồng bộ thủ công hai thư mục làm việc này, điều này cho phép tôi cảm thấy thoải mái hơn rất nhiều khi mọi thay đổi trong thư mục làm việc của tôi là những gì tôi dự định có.

Có điều gì tôi có thể làm để giúp những nhân viên này học Git không?

Bạn có chắc chắn rằng vấn đề là Git chứ không phải cái gì khác? Những gì tôi nhận được từ nhận xét là quản lý đã quyết định thay đổi một cái gì đó mà không mua từ những người đóng góp cao cấp và đang giao nhiệm vụ cho ai đó để họ thay đổi. Đó dường như là một điểm khởi đầu tốt cho thất bại, những gì đã từng thay đổi. Sự phức tạp của Git không phải là một vấn đề, vấn đề là một sự thay đổi mà họ không cảm thấy cần phải áp dụng cho họ.

Vì vậy, đừng tập trung vào cách dạy họ Git, miễn là họ không thấy lợi thế cho công tắc họ sẽ kéo chân họ. Chỉ cho họ cách Git là một giải pháp cho các vấn đề họ có bây giờ. Không phải làm thế nào Git có thể cung cấp cho họ những thứ mà họ chưa cảm thấy cần, không phải là cách Git cung cấp giải pháp cho các vấn đề của người khác, cách Git giải quyết các vấn đề mà họ đang đấu tranh. Sau đó, dạy họ Git sẽ là một vấn đề không.

Thông thường Git được đưa vào sử dụng tại một công ty để giải quyết các vấn đề với các chi nhánh. Vâng, nó tốt hơn ở các nhánh sau đó là Subversion, nhưng nó không làm được điều gì kỳ diệu.

Rất có khả năng các nhà phát triển có kinh nghiệm đã làm việc trong nhiều công ty có.

• Các chi nhánh được tạo ra vì ban quản lý không sẵn sàng quyết định giữa các nhu cầu xung đột
• Đã sử dụng một chi nhánh cho mỗi khách hàng thay vì chuyển đổi cấu hình.
• Phải có một chi nhánh sửa lỗi cho mỗi khách hàng vì ban quản lý không sẵn sàng làm cho tất cả khách hàng nâng cấp lên cùng một phiên bản phần mềm
• Vân vân.

Vì vậy, ngay khi một số người nói với tôi rằng một công cụ tốt trong việc phân nhánh tâm trí tôi nói với tôi.

Ban quản lý không muốn quyết định công ty sẽ đi theo con đường nào, và thà rằng tôi đã lãng phí cuộc đời khi phải hợp nhất công việc của mình thành 101 chi nhánh khác nhau, cùng với việc phải thử nghiệm 101 bản phát hành phần mềm khác nhau.

Ngoài ra, khái niệm hai người sẽ làm việc trên cùng một tệp là cùng một người, đó là không thể chấp nhận được đối với một người đã trải qua một dự án chạy tốt, do đó quảng bá Git như một công cụ để làm như vậy, khó có thể có kinh nghiệm nhà phát triển thích bạn.

Mỗi lần tôi nhìn vào lịch sử trong Git, rất khó để biết tại sao mã lại thay đổi, vì 50% hoặc hơn lịch sử được hợp nhất mà logic không bao giờ nên được công khai và chúng trở nên vô nghĩa ngay khi mã rời khỏi nhà phát triển máy móc.

Nhưng tôi rất thích làm việc ở đâu đó:

• Không có mã nào được đưa vào hệ thống trung tâm cho đến khi nó được biên dịch và thử nghiệm đơn vị trên một máy chủ tin cậy.
• Có một cách dễ dàng để theo dõi đánh giá mã
• Bất cứ khi nào tôi thực hiện một trò chơi get Nhận, mã luôn luôn biên dịch và hoạt động
• Nơi tôi có thể thúc đẩy những thay đổi của mình mà không cần phải chạy đua với người khác, hoặc phải đi lạc trong văn phòng để xem liệu tôi có phá vỡ bản dựng hay không.

Vì vậy, hãy giải quyết các vấn đề thực sự và nếu Git là một phần của các giải pháp mà các nhà phát triển có kinh nghiệm của bạn sẽ mua, nhưng đừng hy vọng họ sẽ thích Git chỉ vì đây là một món đồ chơi tuyệt vời có thể thực hiện phép thuật sát nhập.

Do đó, bất cứ nơi nào cho phép nhà phát triển đẩy từ Git cục bộ của họ sang Git trung tâm đều làm sai, quy trình tự động được kiểm soát sẽ thực hiện các thay đổi từ nhà phát triển và sau khi thử nghiệm chúng, v.v. và kiểm tra các phép hợp nhất có thể cập nhật tất cả Git trung tâm chi nhánh vv không được quan tâm lâu dài.

Tôi hy vọng rằng Kiln ( http://www.fogcalet.com/fogormsz/devhub ) hoặc thậm chí GitHub sử dụng một yêu cầu kéo của Wap làm cho các nhà phát triển có kinh nghiệm hài lòng, ví dụ: đừng bắt đầu với mức độ thấp, hãy bắt đầu với mức độ được cải thiện quá trình.