Git làm việc chiến lược - nhiều tính năng, phiên bản rất thường xuyên

Question

đây là mô tả về công việc hàng ngày của tôi:

Hai nhà phát triển làm việc trong nhiều tính năng nhỏ hoặc sửa chữa, giả sử 3-4 mỗi ngày đối với mỗi nhà phát triển. tôi cần để có thể làm việc trên các tính năng A - B - C cùng một lúc, trong khi đồng nghiệp của tôi hoạt động trên tính năng D và E.

thứ hai: Tính năng A được đẩy lên một dàn máy chủ để xem xét khách hàng . Tính năng B được đẩy đến cùng một máy chủ dàn dựng để xem xét khách hàng. Tính năng D được đẩy đến cùng một máy chủ dàn dựng để xem xét khách hàng.

Thứ Ba: Chúng tôi nhận được sự chấp thuận của khách hàng cho A và D (nhưng không phải cho B). Và họ cần phải sống với những thay đổi đó ngay lập tức.

Thứ tư: Tính năng C được đẩy tới cùng một máy chủ dàn xếp để xem xét khách hàng. Phê duyệt cho B cuối cùng cũng được nhận.

Thứ năm: Tính năng B phải được đẩy vào sản xuất ngay lập tức.

Thứ sáu: Lỗi được phát hiện trong bản phát hành sản phẩm cuối cùng và chúng tôi cần quay lại phiên bản trước.

Điều này không thể coi là quá trình giống như Scrum vì không có khả năng nhóm các đối tượng thành Câu chuyện hoặc lập kế hoạch chạy nước rút. Điều này giống như một quy trình bảo trì (có thể là Kanban?).

Bạn có thể đưa ra ví dụ về cách bạn xử lý việc này bằng Git không? Giả sử rằng ngay bây giờ, chúng ta chỉ có một nhánh chính và bất cứ khi nào chúng ta muốn đẩy bất cứ thứ gì để dàn dựng hoặc sản xuất, chúng ta phải "git pull" thực hiện tất cả các thay đổi trực tiếp (ngay cả những cái không mong muốn). Còn về git "cherry-pick" để lấy các cam kết cụ thể? Một chi nhánh cho mỗi đối tượng địa lý có vẻ quá ghê tởm vì chúng tôi có quá nhiều tính năng. Nếu bạn có thể đưa ra các ví dụ cụ thể về các lệnh và các nhánh của Git (chỉ để hiển thị ý tưởng chính, không cần phải chính xác 100%), điều đó thật tuyệt vời.

Cảm ơn.

Answer 1

cuối cùng tôi đã chọn cách sau xử lý này:

• Một Thạc sĩ kho từ xa.
• Chi nhánh địa phương trên dàn dựng.

• Một chi nhánh địa phương về sản xuất.

  git checkout -b staging #on staging server
git checkout -b production #on production server

Programmer A có nhu cầu làm việc trên một tính năng/vá A:

#local development box 
git checkout master 
git checkout -b issue-A 
#work on the feature 
git push origin issue-A 
#log in to the staging server 
git checkout staging 
git pull origin issue-A #merge with the staging branch, changes are live on staging. 

Cũng vậy với lập trình viên B làm việc trên tính năng B.

Đi trực tiếp sản xuất:

#log in to the production server. 
git checkout production 
git pull origin issue-A #merge with the production local branch, changes are live on production. 

Ngoài ra, chi nhánh sản xuất địa phương có thể được đẩy để làm chủ khi thay đổi này là sống và đã được phê duyệt:

git add <files> 
git commit <commit info> 
git push origin master 

Đây là những gì làm việc tốt nhất trong tình huống của chúng tôi, hy vọng nó sẽ giúp một ai đó.

Answer 2

Chúng tôi đã sử dụng luồng git cho các trường hợp như thế này.

Vì luồng git cho phép bạn tạo nhiều tính năng và chỉ đẩy các đối tượng địa lý mà bạn muốn thông qua các nhánh phát triển và nhánh chính, nên nối đuôi phù hợp với yêu cầu của bạn.

đây là một số liên kết cho git-dòng chảy:

https://github.com/nvie/gitflow/ http://yakiloo.com/getting-started-git-flow/

Answer 3

Tôi đã thích nghi git-dòng này: https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

sự khác biệt lớn nhất là bạn bắt đầu tất cả các tính năng từ cùng một khởi đầu cho một lần chạy nước rút/itteration.

Answer 4

Từ những gì bạn đã mô tả, tôi sẽ áp dụng chiến lược của chi nhánh phát hành và nhiều chi nhánh đang hoạt động.

Ý nghĩa: Bạn nên thiết lập máy chủ dàn của bạn để chỉ kéo từ chi nhánh staging trong khi bạn và đồng nghiệp của bạn đều làm việc trên các ngành chức năng của riêng bạn (A, B, C và có lẽ chính)

Bất cứ khi nào một sự thay đổi phải đi vào hoạt động, bạn chỉ cần kết hợp tính năng vào chi nhánh staging và đẩy nó vào máy chủ - sau đó kéo nhánh đó ra và kéo nhánh đó ra và triển khai.

Một khi bạn đã có sự chấp thuận của khách hàng của bạn thì bạn có thể đẩy chi nhánh tính năng (nghĩa là đã sáp nhập vào staging vào một chi nhánh (có thể stable) và sau đó triển khai đến sản xuất.

Khi trong sản xuất, bạn có thể xóa các chi nhánh tính năng và bắt đầu lại ..

TLDR: hãy đối xử với mỗi người trong môi trường của bạn như là một chi nhánh mà chỉ được đẩy lên khi một tính năng có đến đó Bằng cách đó bạn thậm chí có thể trở lại những thay đổi từ các chi nhánh/môi trường. không được đến đó.

Và tôi muốn đi với một phương pháp Kanban - dễ dàng hơn và cho những gì bạn có vẻ làm phù hợp hơn.