Nhà phát triển mới không thể theo kịp sự hợp nhất chi nhánh

Tôi là nhà phát triển mới - đây là vị trí lập trình đầu tiên của tôi.

Vấn đề của tôi là: Chúng tôi sử dụng git- Tôi cắt một nhánh từ developchi nhánh của mình, sau đó tôi bắt đầu thực hiện nhiệm vụ nhỏ mà tôi được giao. Nó rất chậm, vì tôi thiếu kinh nghiệm. Vào thời điểm tôi sẵn sàng hợp nhất chi nhánh của mình lại với developcác chi nhánh khác, tôi đã thực hiện rất nhiều thay đổi để giải quyết các xung đột là quá sức (thực sự có vẻ dễ dàng hơn để loại bỏ công việc của tôi và bắt đầu lại nhiệm vụ, tất nhiên đó không phải là một giải pháp bền vững ).

Làm thế nào để tôi vượt qua điều này? Có một chiến thuật nào tôi có thể sử dụng ngoài việc 'giỏi mã hóa hơn' không? Tôi dự định sẽ mang nó lên với người giám sát của tôi vào tuần tới.

Trong khi đó, bạn nhận được xung đột hợp nhất nếu những thay đổi bạn đã thực hiện trong chi nhánh của mình gần với những thay đổi mà đồng nghiệp của bạn đã thực hiện trong developchi nhánh, nghĩa là, nếu bạn và đồng nghiệp của bạn thay đổi cùng một dòng mã hoặc các dòng liền kề trong cùng một tệp.

Vì vậy, để giảm khả năng xung đột hợp nhất, bạn có thể cố gắng hợp nhất sớm hơn để đồng nghiệp của bạn thay đổi ít dòng hơn trong thời gian đó hoặc bạn có thể cố gắng tự thay đổi ít dòng hơn.

Để tự thay đổi ít dòng hơn, hãy đảm bảo chỉ thực hiện các thay đổi liên quan đến nhiệm vụ của bạn.

Nếu bạn cần thử nghiệm các cách khác nhau để đạt được mục tiêu của mình, có thể một số thử nghiệm của bạn đã thay đổi các dòng không thực sự cần phải thay đổi? Hoàn tác những thay đổi này trước khi hợp nhất.

Ngoài ra còn có một số lệnh Git có thể giúp bạn thay đổi càng ít dòng càng tốt:

• git diffvà git diff --stagedđể xem những dòng bạn đã thay đổi.
• git add -p để chỉ thêm một số thay đổi của bạn trong một tệp.
• git commit --amendvà git rebase -iđể điều chỉnh các cam kết bạn đã thực hiện trong nhánh tính năng cục bộ của mình trước khi đẩy chúng sang các kho Git khác.

(Thay đổi như vài dòng càng tốt cũng có thể làm cho nó dễ dàng hơn để xem xét công việc của bạn hoặc sử dụng công cụ mà làm việc về sự khác biệt giữa các cam kết như git cherry-pick, git rebase, git bisect, và git blame.)

Nhưng ngay cả khi bạn giảm khả năng xung đột hợp nhất, đôi khi bạn vẫn sẽ gặp phải xung đột hợp nhất. Vì vậy, đừng sợ chúng, nhưng hãy học cách giải quyết các xung đột.

Tôi giả sử bạn đang sử dụng git. Nếu vậy, hãy sử dụng git rebase -i( -iphương tiện tương tác). Làm cho nó trở thành một nhiệm vụ hàng ngày (thậm chí thường xuyên hơn, nếu cần thiết) để chống lại chi nhánh của bạn chống lại chi nhánh phát triển. Điều này mang lại những thay đổi tăng dần mỗi ngày (ít nhất) để giữ cho chi nhánh tính năng của bạn được cập nhật. Nếu có mâu thuẫn trong cuộc nổi loạn hàng ngày của bạn, bạn cần nói chuyện với nhóm của bạn về việc ai đang làm việc gì.

Nếu bạn chạy nó hàng ngày, có lẽ bạn sẽ không cần phần tương tác. Hãy để nó làm việc của nó.

Tôi là một nhà phát triển khá có kinh nghiệm và tôi vẫn mất khá nhiều thời gian để bắt kịp tốc độ trong một dự án mới. Trong trường hợp của bạn, có vẻ như bạn có nhiều người cùng làm việc trong cùng một dự án, vì vậy đó là một dự án rất lớn hoặc một dự án mới đang phát triển nhanh chóng. Trong cả hai trường hợp, đừng lo lắng nếu bạn mất vài tháng để hòa vào dòng chảy. Nếu tôi chuyển đổi dự án trong 2 hoặc 3 tuần và sau đó chuyển đổi lại, tôi có thể mất vài giờ (hoặc thậm chí một hoặc hai ngày) để hoàn toàn "quay lại" một dự án mà tôi đã tự viết 100%!

Nói tóm lại, đừng lo lắng về việc bị chậm ngay bây giờ. Cách để tốt hơn là cứ tiếp tục luyện tập. Đừng ngại hỏi các nhà phát triển khác về các khía cạnh của các dự án bạn không hiểu.

BIÊN TẬP:

Hoặc sử dụng merge. Đó cũng là một lựa chọn. Vì vậy, ở trên sẽ là: "sử dụng git rebase -i( -icó nghĩa là tương tác) hoặc git merge". Đối với cái nào sẽ sử dụng, hãy nói chuyện với phần còn lại của nhóm bạn. Họ có thể (hoặc có thể không) có sở thích mạnh mẽ theo cách nào. Rõ ràng một số người làm có sở thích mạnh mẽ.

Đây có thể là một dấu hiệu của kỹ thuật phần mềm xấu về phía công ty. Quá nhiều phụ thuộc lẫn nhau, các vấn đề khác nhau với các tính năng chồng chéo, cố gắng giải quyết các vấn đề theo thứ tự sai, vv có thể gây ra tình huống bạn đang mô tả. Tôi đề nghị thường xuyên sáp nhập developvào chi nhánh của bạn trong quá trình phát triển

Các câu trả lời được chấp nhận tôi nghĩ là thiên về kỹ thuật "làm thế nào để sử dụng Git tốt hơn", tôi nghĩ rằng đây là vấn đề của nhóm nhiều hơn là vấn đề về kỹ thuật hoặc công cụ.

Nếu bạn gặp phải nhiều xung đột hợp nhất, điều đó có nghĩa là bạn và ai đó trong nhóm đang giẫm lên các ngón chân của nhau.
Bạn hoặc họ nên đặt mục tiêu phát triển không gian cá nhân trong khi mã hóa và tránh làm việc trong các khu vực đã bận rộn.

Trong nhóm của tôi, chúng tôi có xu hướng hướng tới mức độ cao của quyền sở hữu nhiệm vụ.
Tôi thường sẽ sở hữu đầy đủ và đầy đủ hai hoặc ba tệp cùng một lúc và làm việc với chúng trong một nhánh nhiều nhất là một hoặc hai ngày.
Thông thường nếu bất kỳ ai khác chạm vào các tệp đó thì chỉ khi thực sự cần thiết cho các tác vụ của riêng họ, chúng ta thường không làm việc cùng nhau trên cùng một khối nhiệm vụ!

Nếu bạn thấy rằng bạn phải hợp nhất rất nhiều thì tất cả mã nhóm của bạn đều ở một nơi (đó là điều cần tránh trong chính nó) hoặc tất cả các nhiệm vụ của bạn là.

Tất cả những gì đã nói, với tư cách là một nhà phát triển mới, có lẽ bạn không ở vị trí để thực thi, yêu cầu hoặc thậm chí thực sự đề xuất bất kỳ loại tái cấu trúc nào.
Điều tôi mong đợi là các nhiệm vụ của bạn đã được chỉ định là công cụ "học hỏi" có thể tiếp cận hợp lý ở cấp độ kỹ năng của bạn để giúp bạn dễ dàng tham gia vào nhóm. Có lẽ họ đã bị loại bỏ khỏi các nhiệm vụ của một đồng nghiệp vẫn đang làm việc trong cùng khu vực, do đó xung đột hợp nhất của bạn.
Giải pháp cho vấn đề này là giải quyết vấn đề, giải quyết các vấn đề, giải quyết các xung đột hợp nhất một cách tốt nhất có thể và đừng quá lo lắng, miễn là bạn đang cố gắng hết sức để quản lý của bạn lo lắng về sự tiến bộ của bạn
Bạn sẽ nhanh hơn và tự tin hơn khi bạn đi,

Điều quan trọng nhất của việc hợp nhất là bạn càng chờ đợi lâu, nó càng đau đớn. Và vấn đề phát triển hơn tuyến tính. Nhiều gấp ba lần xung đột là gấp chín lần công việc. Có một số chiến lược:

Hợp nhất với nhánh phát triển bất cứ khi nào nó thay đổi, vì vậy bạn luôn ở gần nó và không bao giờ có một số lượng lớn các xung đột.

Nếu bạn mất nhiều thời gian, thì đó có thể là do bạn dành phần lớn thời gian để tìm ra những thay đổi là gì, và sau đó một lượng nhỏ thời gian để thực hiện các thay đổi. Nếu đó là trường hợp, hợp nhất với nhánh phát triển trước khi bạn bắt đầu thay đổi mã thực tế.

Nói chuyện với các đồng nghiệp của bạn về các chiến lược để tránh xung đột. Bạn nhận được xung đột nếu hai người chỉnh sửa cùng một mã. Không chỉ cùng một tệp, mà cùng một mã. Vì vậy, tôi cần một hàm chức năng mớiA và bạn cần một hàm chức năng mớiB và cả hai chúng tôi đều thêm nó vào cuối cùng của một tệp, chúng tôi có một xung đột. Nếu chúng ta thêm nó ở những nơi khác nhau, không có xung đột. Nếu cả hai chúng ta thêm nó vào một vị trí trong tệp nơi nó thuộc về logic, rất có thể chúng ta không có xung đột.

Nếu bạn có xung đột, hãy sử dụng một công cụ tìm khác biệt tốt, để bạn có thể so sánh nhánh phát triển trước khi hợp nhất, mã của bạn trước khi hợp nhất, mã gốc và mã được hợp nhất và hợp nhất bằng tay.

Trường hợp xấu nhất: Bạn không vứt bỏ công việc của mình, nhưng sử dụng một công cụ tìm khác biệt tốt để tìm hiểu chính xác những thay đổi bạn đã thực hiện, phân nhánh lại từ phát triển và áp dụng tất cả các thay đổi bạn đã thực hiện thay vì thử lại chúng.

Vào thời điểm tôi sẵn sàng hợp nhất chi nhánh của mình để phát triển (nhấn mạnh vào tôi)

Xử lý xung đột trong git mergethường đơn giản hơn trong git rebase. Trong hợp nhất Git, bạn có thể thấy toàn bộ danh sách các tệp đã được sửa đổi cùng một lúc. Cho dù có bao nhiêu cam kết đã được thực hiện bởi các đồng nghiệp khác, bạn sẽ phải hợp nhất một lần . Với quy trình làm việc rebase, cuối cùng bạn có thể gặp phải những xung đột tương tự và phải xem xét lại chúng một cách thủ công. Cuối cùng, bạn có thể sửa lỗi cam kết thứ 13 và cảm thấy như bạn không thể nhìn thấy ánh sáng từ đường hầm .

Theo kinh nghiệm của tôi, khi tôi cố gắng giải quyết một cách ngây thơ các cuộc xung đột lặp đi lặp lại, cuối cùng tôi đã mất các sửa đổi của ai đó hoặc với một ứng dụng thậm chí không được biên dịch. Thường thì tôi và đồng nghiệp đã làm rất nhiều việc nhưng bị choáng ngợp bởi sự phức tạp của việc lặp lại xung đột đến mức chúng tôi phải hủy bỏ và mất công việc trước đây sau một vài lần phản công.

Tôi sẽ gợi ý cho bạn một vài kỹ thuật nhưng chúng chỉ có thể giúp việc hợp nhất trở nên dễ dàng hơn là tự động hóa nhiệm vụ.

• Tập tin tài nguyên / ngôn ngữ . Nếu bạn có các thay đổi phụ gia đối với tệp tài nguyên, hãy đảm bảo bạn luôn di chuyển chúng đến cuối tệp để bạn có thể dễ dàng nhớ lại các thay đổi của mình đối với các thay đổi của người khác . Bạn có thể sao chép và dán các thay đổi của mình ở phía dưới hoặc chỉ cần xóa các dấu xung đột
• Làm. Không phải. CHẮC CHẮN RỒI. Định dạng RE . Cả bạn và nhà phát triển đồng nghiệp của bạn sẽ không thực hiện "định dạng lại mã lớn" trong công việc hàng ngày. Định dạng lại mã bổ sung quá nhiều số dương tính giả trong quản lý xung đột. Định dạng lại mã có thể được thực hiện
  • Tăng dần, ví dụ như bởi mọi nhà phát triển trên mỗi cam kết, ngay khi họ sử dụng một công cụ tự động (ví dụ: Eclipse có một tùy chọn để định dạng lại lưu, vanilla Visual Studio không có). Tuyệt đối mọi nhà phát triển phải sử dụng các tiêu chuẩn định dạng mã giống nhau, được mã hóa thành một tệp định dạng được IDE của bạn ăn. Để cho bạn một ý tưởng, nếu đó là 4 khoảng trắng hoặc 2 tab thì điều đó không thành vấn đề, nhưng nó thực sự quan trọng nếu mọi người đều sử dụng như nhau.
  • Ngay trước khi phát hành, bởi một trưởng nhóm. Nếu một cam kết "định dạng lại mã" xảy ra khi mọi người không làm việc trên các nhánh, tức là trước khi họ phân nhánh, mọi việc sẽ trở nên dễ dàng hơn
• Xem lại công việc phân chia giữa các đồng nghiệp. Đây là một phần mà hầu hết các kỹ thuật đến. Như được chỉ ra bởi các câu trả lời khác, đó là mùi thiết kế nếu nhiều nhà phát triển thực hiện các nhiệm vụ khác nhau phải chạm vào cùng một tài nguyên. Bạn có thể phải thảo luận với trưởng nhóm của mình về phần nào sẽ được sửa đổi bởi mỗi nhà phát triển đồng thời.

Tôi cũng đã thấy một số thói quen xấu trong quy trình làm việc của Git trong các nhóm của tôi. Mọi người thường quá quan tâm đến các chi nhánh của họ. Cá nhân tôi đã chứng kiến ​​một nhà phát triển thêm 10 đến 20 cam kết được gắn nhãn "sửa chữa", mỗi cam kết một hoặc hai dòng. Chính sách của chúng tôi là các cam kết được dán nhãn bằng vé JIRA để cung cấp cho bạn một ý tưởng.

@JacobRobbins đề nghị thực hiện git rebasemột nhiệm vụ hàng ngày. Tôi muốn đẩy cách tiếp cận của mình về phía trước.

Đầu tiên, sử dụng rebase một lần chỉ để giảm số lượng cam kết xuống một số ít. Và rebase chỉ vào nhánh phát triển ban đầu , đó là cam kết mà bạn đã phân nhánh. Khi tôi nói một cách khéo léo, tôi có thể có nghĩa là 3 hoặc 4 (ví dụ: tất cả mặt trước, tất cả mặt sau, tất cả các bản vá cơ sở dữ liệu) hoặc bất kỳ con số hợp lý nào của con người. Sau khi bạn đã hợp nhất chúng, hãy sử dụng fetchvà thực hiện rebase của bạn trên nhánh ngược dòng. Điều này sẽ không cứu bạn khỏi xung đột trừ khi nhóm của bạn xem xét phương pháp của riêng họ, nhưng sẽ khiến cuộc sống của bạn bớt đau đớn hơn.

Nếu bạn có thêm câu hỏi về các nhiệm vụ cụ thể, vui lòng tìm kiếm và hỏi về Stackoverflow.

[Chỉnh sửa] về quy tắc trinh sát không định dạng lại và cậu bé. Tôi đã định dạng lại một chút định dạng RE để làm nổi bật rằng ý nghĩa của tôi là nhiệm vụ định dạng từ đầu toàn bộ tệp nguồn, bao gồm cả mã không được bạn chạm vào. Ngược lại, luôn định dạng mã của riêng bạn, đó là hướng đạo sinh hoàn hảo, một số nhà phát triển, bao gồm cả tôi, được sử dụng để định dạng lại toàn bộ tệp với các khả năng của IDE. Khi tệp bị người khác chạm vào, ngay cả khi các dòng bị ảnh hưởng không được thay đổi trong nội dung và ngữ nghĩa của chúng, Git sẽ xem đó là một xung đột. Chỉ có một trình soạn thảo nhận biết ngôn ngữ rất mạnh mới có thể gợi ý rằng xung đột chỉ liên quan đến định dạng và tự động hợp nhất đoạn được định dạng tốt nhất. Nhưng tôi không có bằng chứng về bất kỳ công cụ nào như vậy.

Rốt cuộc, quy tắc trinh sát của cậu bé không bắt buộc bạn phải dọn dẹp mớ hỗn độn của người khác. Chỉ là của bạn.

Đầu tiên, đừng nghĩ về việc loại bỏ những thay đổi của bạn. Bạn sẽ mất cơ hội để tìm hiểu quá trình hợp nhất.

Thứ hai, tìm một người làm việc trên các tập tin gây ra xung đột. Bạn có thể xem lịch sử. Nói chuyện với người đó và giải quyết xung đột trong các tập tin đó. Làm tương tự cho các xung đột khác.

Nếu có quá nhiều xung đột, nhiệm vụ của bạn có thể là một lỗi nhỏ, nhưng lặp đi lặp lại. Cố gắng tìm một mô hình. Điều này sẽ giúp giải quyết xung đột bằng các công cụ máy khách Git UI. Tôi sử dụng TortoiseGit. Nó giúp hợp nhất.

Và để tránh trong tương lai,

• Đó là một thực tiễn rất tốt để hợp nhất nhánh phát triển thường xuyên với nhánh tính năng của bạn.

• Nếu bạn đã bật CI, hãy xem công cụ CI có cung cấp bản dựng chi nhánh không. Điều này sẽ được xây dựng trên mỗi kiểm tra bạn thực hiện trong nhánh tính năng của mình, nhưng sau khi hợp nhất phát triển nhánh.

Bạn nên chạy thường xuyên (hàng ngày) lệnh 'git fetch' (không phải git pull) từ nhánh phát triển của bạn. Điều này sẽ khiến những người khác cam kết thay đổi và đưa họ vào nhánh tính năng của bạn mà không cố gắng tích hợp các thay đổi vào chi nhánh của bạn.

Đây là điều bạn nên nói với nhà phát triển chính (không nhất thiết phải là người quản lý của bạn), bởi vì công ty của bạn có thể có các tiêu chuẩn riêng hoặc các cách được đề xuất để xử lý vấn đề này; nó rất phổ biến Đừng đợi đến tuần sau - hãy tìm hiểu quy trình ngay bây giờ và hỏi xem bạn có thể thực hiện một số công việc không quan trọng (như định dạng mã hoặc thêm nhận xét) để bạn có thể kiểm tra quy trình.

Rõ ràng điều đầu tiên là để tránh việc nhiều người làm việc trên cùng một tệp ở vị trí đầu tiên, ít nhất là theo cách dẫn đến xung đột khó khăn. Thêm mọi thứ vào bảng liệt kê không có vấn đề gì miễn là sử dụng định dạng mã tốt. Thay đổi luồng điều khiển theo nhiều cách khác nhau và di chuyển mã xung quanh khó khăn hơn nhiều. Đôi khi điều này là không thể tránh khỏi dù sao. Bạn sẽ cần đặt câu hỏi khi giải quyết xung đột thực sự phức tạp.

Điều đó nói rằng, tôi thấy nhiều câu trả lời đề nghị hợp nhất / rebase để phát triển thường xuyên. Tôi sẽ ít nhiệt tình hơn về loại lời khuyên đó. Mục tiêu của bạn tại thời điểm này là làm cho quá trình giải quyết xung đột trở nên dễ dàng và an toàn nhất có thể. Một điều sẽ giúp rất nhiều cho quá trình đó là có sẵn nhiều bài kiểm tra hồi quy, bao gồm cả những bài kiểm tra mới là một phần của tính năng mới của bạn. Nếu bạn đồng bộ hóa chi nhánh của mình rất thường xuyên với phát triển, cuối cùng bạn sẽ phải giải quyết xung đột trong khi bạn thực sự hoàn thành một nửa việc thực hiện tính năng của mình. Và điều đó có nghĩa là sẽ khó khăn hơn nhiều khi cố gắng tìm ra những gì mã phải làm, như bạn đã làm với nó. Trước khi thử hợp nhất, hãy đảm bảo rằng chi nhánh của bạn là một đơn vị thay đổi mạch lạc. Thậm chí còn tốt hơn,

Tôi đã cố gắng không đi vào giá trị của rebase trên hợp nhất mà có lẽ là cho một câu hỏi khác. Trong bối cảnh này, các công cụ không thực sự quan trọng.

Vào thời điểm tôi sẵn sàng hợp nhất chi nhánh của mình để phát triển, những người khác đã thực hiện rất nhiều thay đổi để giải quyết xung đột là quá sức

Điều này nghe có vẻ là một kịch bản lý tưởng cho lập trình cặp !

Thông tin thêm về các lợi ích và cách tiếp cận cơ bản:
https://gds.blog.gov.uk/2018/02/06/how-to- Pair-program-effect-in-6-steps /

Bạn sẽ tự nhiên tăng tốc theo thời gian từ việc tự làm việc, nhưng nó có thể gây nản chí cho đến khi thời điểm đó đến, và đôi khi cũng là một quãng đường dài. Ngoài ra, trong khi mọi người có thể học nhanh chóng trong một môi trường căng thẳng luôn bị áp lực để bắt kịp, những người khác không học tốt dưới áp lực liên tục sẽ bị cản trở.

Thay vì tự mình làm việc trên một chi nhánh và cố gắng theo kịp các nhà phát triển khác, những người rõ ràng nhanh hơn bạn rất nhiều, thay vào đó bạn sẽ làm việc trực tiếp (cùng PC) với một nhà phát triển khác. Bằng cách này bạn sẽ nhận được lời khuyên ngay lập tức và có thể sẽ nhận các mẹo về cách tăng tốc, v.v.

Bạn đã tìm ra cách tiếp cận tốt nhất cho mã cụ thể trong dự án của mình, vì lập trình cặp không phải lúc nào cũng có ý nghĩa đối với một số dự án - mặc dù nó luôn có ý nghĩa cho việc học ngay cả khi bạn chỉ ngồi và xem ai đó có kinh nghiệm hơn bạn (miễn là họ là một nhà phát triển tốt, kinh nghiệm không nhất thiết có nghĩa là họ sử dụng các thực hành tốt).

Ngồi với một dev nhanh hơn, nhiều kinh nghiệm hơn có khả năng giúp đỡ bằng cách:

• Sẽ có khả năng giảm xung đột hợp nhất khi làm việc với người có kinh nghiệm hơn sẽ tăng thời gian hoàn thành thay vì làm việc một mình
• Vì họ sẽ dạy bạn, có khả năng họ sẽ chậm hơn so với khi họ làm việc một mình, do đó, vẫn có thể có một số xung đột hợp nhất và vì vậy có thể giải quyết chúng với ai đó dày dạn và vì vậy có thể chọn một số mẹo về tiết kiệm thời gian, v.v.
• Giúp bạn thấy các thủ thuật tiềm năng và cách để nhanh hơn (mặc dù chậm đôi khi chỉ đơn giản là thiếu kinh nghiệm hơn là thiếu thực hành tốt)
• Có thể đặt câu hỏi ngay lập tức khi điều gì đó không có ý nghĩa hoặc không rõ ràng 100%
• Làm việc 1: 1 rất có giá trị cho việc học vì người bạn sẽ yêu cầu trợ giúp đã hiểu chính xác mã và kịch bản khi họ đang làm việc với nó, không cần lập trình cặp, bạn phải giải thích mã và kịch bản, thường kết thúc một vấn đề và vì vậy bạn mất thời gian / sự chú ý của họ vào việc thực sự nhận được nhiều lời khuyên cần thiết
• Tìm hiểu quá trình suy nghĩ của một người có kinh nghiệm và dày dạn hơn, và với sự giao tiếp tốt, bạn chắc chắn sẽ học được những điều mới

Có một chiến thuật nào tôi có thể sử dụng ngoài việc 'giỏi mã hóa hơn' không? Tôi dự định sẽ mang nó lên với người giám sát của tôi vào tuần tới.

Lời khuyên của tôi là thảo luận về lập trình cặp với các nhà phát triển khác và sau đó tiếp cận người giám sát của bạn. Nếu họ tử tế, họ sẽ đánh giá cao sáng kiến ​​của bạn, điều này có nhiều cơ hội hơn để bạn đưa ra những ưu điểm của lập trình cặp (nếu họ cần điều đó, hầu hết mọi người đều biết về nó và đó là kiến ​​thức phổ biến tại sao nó giúp ích).

Có một vài vấn đề tiềm ẩn ở đây. Các vấn đề của bạn hợp nhất rất có thể không phải là lỗi của bạn và thường là một triệu chứng của các thực hành xấu.

1) Lý tưởng nhất là bạn sẽ hợp nhất chi nhánh của mình để phát triển mỗi ngày. Cố gắng có mã làm việc ít nhất một lần một ngày vượt qua tất cả các bài kiểm tra để bạn có thể hợp nhất để phát triển.

2) Nếu bạn không có mã làm việc tại bất kỳ thời điểm nào trong ngày làm việc thông thường của bạn, bạn có thể có quá nhiều mã để làm việc. Bạn cần chia nhiệm vụ của mình thành các nhiệm vụ nhỏ hơn để có thể hoàn thành (lý tưởng độc lập với nhau) nhanh hơn để bạn có thể hợp nhất.

3) Các tập tin dự án của bạn có thể quá lớn. Nếu có nhiều xung đột hợp nhất cho một tệp thì có quá nhiều người làm việc trên một tệp. Lý tưởng nhất là một người đang làm việc nên tách biệt với những gì mọi người đang làm việc.

4) Nhóm của bạn có thể quá lớn. Nếu bạn thấy dễ dàng hơn để loại bỏ toàn bộ một tính năng và bắt đầu lại, có thể có quá nhiều người cam kết mã vào cùng một kho lưu trữ.

5) Bạn có thể không có tiêu chuẩn định dạng mã nhất quán. Nếu bạn không nhất quán sử dụng cùng một định dạng mã, bạn sẽ gặp nhiều xung đột khác nhau cho cùng một mã. Tùy thuộc vào cách git của bạn được thiết lập, những điều này thậm chí có thể dẫn đến xung đột khoảng trắng (kết thúc dòng, thụt lề, tab so với khoảng trắng).

6) Mọi người có thể đang đẩy những thay đổi của họ trực tiếp đến chi nhánh phát triển.

Đây là những gì bạn có thể làm: 1) Nếu bạn không thể hợp nhất để phát triển mỗi ngày, hãy hợp nhất / rebase phát triển thành chi nhánh của bạn mỗi ngày (hoặc thường xuyên hơn).
2) Cố gắng tách mã của bạn khỏi mã của mọi người.
3) Nói chuyện với phần còn lại của nhóm về các tính năng nhỏ hơn, tiêu chuẩn mã hóa nhất quán và tổ chức mã tốt hơn (tệp nhỏ hơn, chức năng nhỏ hơn).

Nó thực sự có vẻ dễ dàng hơn để loại bỏ công việc của tôi và bắt đầu lại nhiệm vụ, tất nhiên đó không phải là một giải pháp bền vững)

Hầu hết thời gian, đây là những gì tôi làm, lần đầu tiên tôi sửa lỗi hoặc thay đổi hệ thống, tôi đang tìm hiểu về cách thực hiện. Lần sau khi tôi sửa lỗi tương tự, nó chỉ mất 1% thời gian vì bây giờ tôi đã hiểu vấn đề.

Tôi cũng thấy rằng khi tôi làm lại một chút công việc, tôi viết mã tốt hơn .....

Do đó, không có gì sai khi tạo một nhánh mới từ chủ, làm lại công việc của bạn trong đó, trong khi sử dụng "nhánh riêng" của bạn để nhắc nhở bạn những gì bạn cần làm.

Cũng có thể bạn đã phát hiện ra một cách để phân chia thay đổi của bạn thành các phần hợp lý và chính xác, mỗi phần được hợp nhất vào nhánh chính sau khi hoàn thành. Ví dụ, đơn vị kiểm tra và thay đổi mã phụ trợ có thể được thực hiện và hợp nhất. Sau đó, trong một thao tác riêng biệt, bạn có thể thực hiện các thay đổi UI sử dụng chúng, do đó ít có nguy cơ người khác chỉnh sửa cùng một tệp UI.

Nếu bạn không muốn hợp nhất nhánh phát triển vào nhánh của mình quá thường xuyên, bạn có thể nhận được một quy trình công việc giống như svn bằng cách sử dụng git pull --rebase. Điều này sẽ kéo các xác nhận mới và phản hồi lại các cam kết của bạn đối với chúng. Điều này có nghĩa là khi bạn hợp nhất chi nhánh của mình để phát triển, nó sẽ là một sự hợp nhất nhanh chóng (như thể bạn đã thêm tất cả các cam kết trong quá khứ của mình cùng một lúc) và không có bất kỳ xung đột hợp nhất nào, bởi vì bạn đã giải quyết tất cả chúng trong suốt git pull --rebase.

Nhưng bạn càng thực hiện nhiều cam kết trước khi sáp nhập chi nhánh của mình để phát triển hoặc phát triển thành chi nhánh của mình, thì cuộc nổi loạn tiếp theo sẽ càng phức tạp hơn và nó thay đổi ý nghĩa của các nhánh tính năng một chút, vì chi nhánh của bạn chỉ tồn tại miễn là nó không được hợp nhất .

Khi bạn làm việc trong các tệp chung, bằng bất kỳ cách nào, bạn hoặc đồng đội của bạn cần giải quyết tất cả các xung đột trước khi hợp nhất kết thúc do đó tại địa điểm đầu tiên, xin vui lòng đừng buồn . Bạn vẫn đang làm công việc dự án và tự hào về công việc của bạn. Bây giờ để thực hiện một bước đi thông minh hơn, bạn có thể làm theo một số gợi ý dưới đây.

1. Phân chia nhiệm vụ một cách độc lập:

   Trước khi bạn bắt đầu công việc, hãy lập kế hoạch và phân chia toàn bộ các nhiệm vụ theo cách phân công nhiệm vụ cho từng thành viên trong nhóm càng độc lập và mô đun càng tốt (để tránh xung đột tiềm ẩn trong khi phát triển). Bạn có thể tiếp cận với nhà lãnh đạo scrum của mình để giao một số nhiệm vụ độc lập cho bạn khi bạn là người mới.

2. Hợp nhất các cam kết thường xuyên dạng hạt:

   Đừng chờ đợi để hoàn thành nhiệm vụ đầy đủ trước khi sà lan cuối cùng. Tất nhiên bất kỳ nhiệm vụ lớn hơn có thể được phân chia thành nhiều nhiệm vụ. Vì vậy, cách tiếp cận tốt hơn là hợp nhất các cam kết nhỏ hơn cho các nhiệm vụ nhỏ hơn cùng một lúc thường xuyên để tránh giải quyết xung đột cồng kềnh.

3. Rebase chi nhánh của bạn thường xuyên:

   Thực hiện một cuộc nổi loạn thường xuyên đến chi nhánh địa phương của bạn với điều khiển từ xa. Bạn có thể sử dụng lệnh dưới đây để thường xuyên khởi động lại chi nhánh địa phương của mình bằng điều khiển từ xa,

   git pull --rebase #or
   git pull --rebase origin dev #when dev is remote branch
   

   Đó là lệnh git hữu ích nhất đối với tôi trong cuộc đời phát triển của mình.

4. Phối hợp chặt chẽ với đồng đội:

   Nếu bạn thực sự cần phải làm việc song song với đồng đội của mình trong nhiệm vụ chung, hãy làm việc cộng tác. Cô ấy có thể chờ đợi đôi khi để tránh giải quyết xung đột phức tạp để thuận tiện cho bạn vì bạn là người mới và cô ấy là một chuyên gia.

5. Được sử dụng với các tùy chọn git:

   Sử dụng sức mạnh của các công cụ sáp nhập git. Có nhiều cách thuận tiện để giải quyết xung đột trong khi hợp nhất. Chiến lược hợp nhất đôi khi có thể giúp rất nhiều. Được sử dụng và không sợ hãi với các lệnh git.