Việc sử dụng Git có ý nghĩa với các nhóm nội bộ nhỏ không?

Question

Dường như với tôi rằng Git được thiết kế cho các dự án nguồn mở quy mô lớn, với số lượng lớn các nhà phát triển và các nhóm.

Tôi tự hỏi liệu Git có xứng đáng với nhóm nhỏ hơn (< 10) và các dự án nội bộ (trong tổ chức) hay không. Tôi hiểu rằng có một lợi ích hiệu suất rõ ràng để có một bản sao cục bộ của kho lưu trữ (mặc dù đó không phải là khá quan trọng khi kho lưu trữ của bạn bên trong tổ chức của bạn ...).

Bạn vẫn muốn giới thiệu Git (và sự phức tạp đi kèm với nó) và tại sao?

Answer 1

Git không thực sự phức tạp. Và nó là tuyệt vời mạnh mẽ và chính xác. Tôi sẽ không sử dụng bất cứ điều gì khác, cho một dự án một người hoặc một dự án 100.000 người. Tôi thực sự có ý đó.

Tôi hiểu tại sao mọi người nói nó phức tạp, nhưng toàn bộ điều đó bị đánh giá quá cao. Để làm mọi thứ bạn cần làm, có thể có 10 lệnh tối đa bạn cần làm việc. Và bạn không cần phải hiểu mọi lựa chọn của 10 người đó ... chỉ là một vài "công thức nấu ăn" theo kiểu sách dạy nấu ăn.

Điều bạn làm cần hiểu một chút về cách Git khác dưới tiêu đề. Nhưng đó không phải vì git là phức tạp - đó là bởi vì Git là khác nhau. Bạn có thể dành một chút thời gian trong một hoặc hai ngày đào sâu vào thông tin đó, và bạn sẽ rất tốt để đi.

tha thứ cho sự thô lỗ của tôi, nhưng Git làm cho hệ thống tệp của nó là b * tch. Bạn có thể lật giữa "thực tế thay thế" của dự án phần mềm của bạn theo ý thích. Một khi bạn hiểu được công cụ đến từ đâu, bạn sẽ có được sự kiểm soát hoàn toàn giống như thần trên các bit và ký tự bao gồm phần mềm của bạn. Có rất ít công cụ có sức mạnh như vậy dành cho các nhà phát triển phần mềm, thời gian.

Vâng, người đàn ông, tôi khuyên bạn nên sử dụng Git. Làm đi. Bạn sẽ rất vui vì bạn đã làm. Chúc may mắn.

Answer 2

Nó khá đơn giản: Nó làm những gì nó phải làm khá đẹp: kiểm soát phiên bản.

Không hơn, không kém.

Nó hoạt động với IDE của tôi, nó kết hợp các chỉnh sửa nhóm một cách hoàn hảo và tôi có thể kéo mã cũ bất kỳ lúc nào.

Answer 3

Có, vì cách theo dõi thay đổi hoạt động so với svn. (Chỉ đơn giản là ít mâu thuẫn trong các kết hợp nhiều giá trị lớn.)

Có, vì bạn có thể thực hiện các cam kết cục bộ nhỏ trong khi làm việc và sau đó đẩy các thay đổi làm việc hoàn chỉnh vào kho lưu trữ chính. Khi bạn đẩy tất cả các cam kết nhỏ của bạn được đẩy.

Có, bởi vì khi bạn thực hiện một thao tác kéo từ kho lưu trữ chính, nó sẽ không hợp nhất ngay lập tức mà thay vào đó đặt các thứ được kéo vào các nhánh. Hoàn hảo cho khi bạn thực hiện các thay đổi lớn hơn và muốn trì hoãn cập nhật một số ngày trên một số máy tính.

Answer 4

Tôi thích git hơn svn cho các dự án một người. Việc sử dụng các công cụ tương tự trên tất cả các dòng lệnh dễ dàng hơn, và để duy trì cả các khoản git và svn reposities dường như không có lợi cho tôi.

Answer 5

Tôi sẽ nói có.

Thậm chí tôi cũng có xu hướng sử dụng git, vì tất cả các tính năng hữu ích của nó. Không cần phải nhấn mạng (thậm chí là cả nội bộ) cho tất cả nhưng hai hoạt động (đẩy và kéo) là một tiết kiệm thời gian rất lớn trong thời gian dài. Những thứ như kiểm tra các chi nhánh khác nhau chỉ diễn ra tại địa phương, giống như đọc nhật ký.

Lưu ý rằng ngay cả khi git được phân phối, bạn vẫn có thể có các kho trung tâm nơi mọi người đang đẩy và kéo. Nhưng nó chỉ là một kho lưu trữ trung tâm theo quy ước.

Và việc tạo chi nhánh rẻ tiền cũng là một lợi thế. Bạn có thể dễ dàng tạo một nhánh chủ đề nơi bạn triển khai một số tính năng nhỏ, mà sau này bạn hợp nhất lại trong nhánh phát triển.

Xem cho một nhánh chiến lược thành công git flow

Answer 6

tôi sử dụng Git cho một dự án mà tôi chạy một mình (đội size = 1) và cho một dự án với 5 thành viên.

Những lý do tại sao cá nhân tôi thích nó:

• đau branching and merging;
• thiết lập several repositories tích lũy các loại thay đổi khác nhau (hữu ích cho các dự án web);
• hoạt động qua HTTP, SSH, bất kỳ thứ gì (không bao giờ phải suy nghĩ cách kết nối);
• khi bạn quen với quy trình làm việc cam kết cho đến khi tốt-sau-đẩy, bạn thực sự không thể quay lại.

Những lợi ích cho một nhóm thông minh thậm chí còn rõ ràng hơn:

• một lon làm việc trên một chi nhánh trong nhiều tuần mà không lo lắng về việc phải sửa chữa 100 xung đột sau;
• luồng công việc được phân phối có ý nghĩa hơn và cũng tích hợp xem xét mã trong quy trình của bạn.

Tuy nhiên nếu nhóm của bạn là câm (có thể là sự thật đôi khi) hoặc thiên vị chống lại Git, tôi khuyên chống nó bởi vì nó có nỗ lực nhất định và lập trình viên tò mò để học, và không phải tất cả mọi người trong thế giới muốn chi nhánh, hợp nhất, sử dụng quy trình làm việc phân tán hoặc bất cứ thứ gì khác mà Git phải cung cấp.

Answer 7

Git có ý nghĩa đối với cả nhóm lớn và nhỏ. Vâng, git rất phức tạp, nhưng điều đó không có nghĩa là bạn luôn phải đối phó với sự phức tạp đó.Tôi sử dụng git hàng ngày và tôi hiếm khi phát hành bất kỳ điều gì khác ngoài:

git branch # To remind myself what features I'm working on. 
git checkout <name_of_branch> # To switch to whatever I want to work on. 
git checkout -b <name_of_new_feature> # To start work on a new branch 
git add <name_of_file> # To add it to the list of tracked files. 
git commit -m <commit_message> # To checkpoint my work. 
git merge <name_of_branch> # To integrate changes back to trunk. 
git branch -d <name_of_branch> # To delete a branch after it has been merged. 

Chỉ thực sự có một số lệnh bạn cần ghi nhớ hàng ngày. Đối với bất cứ điều gì phức tạp hơn thế, bạn luôn có thể tra cứu nó trong tài liệu.

Một trong những điều tôi thực sự yêu thích về git và tại sao tôi khuyên bạn nên sử dụng nó là bạn có thể giữ cho điểm kiểm tra và phiên bản công việc của mình được kiểm soát ngay cả khi chưa sẵn sàng cam kết với kho lưu trữ. Ví dụ: tôi có thể sử dụng "git commit" nhiều lần, cục bộ, trước khi thực sự hiển thị nó cho các nhà phát triển khác. Điều này đã làm tăng thêm sự tự tin của tôi trong việc thực hiện các thay đổi đối với mã; Tôi có thể thử nghiệm và không lo lắng rằng công việc hiện tại của tôi sẽ bị mất - tôi luôn có thể trở lại phiên bản an toàn nếu có sự cố. Điều này không thể nói về SVN, ví dụ, nơi bất kỳ cam kết nào sẽ được nhìn thấy trong kho lưu trữ chính.