thắc mắc [Git] dùng gì để giải quyết conflict

monster_hunter · 29/8/21

mickey5007 đã nói:
Nhiều người code chung thì conflict là bình thường. Nhưng có bác nào thấy trường hợp code 1 mình mà cũng conflict chưa )

T tự làm tự hủy lun nè. Làm pet project, code trên pc và laptop. Có đợt code trên laptop quên pull về. Thế là conflict sml. :beat_brick:

Sent from Vsmart Active 3 using vozFApp

tien_manh_a2 · 29/8/21

master2811 đã nói:
dùng rebase thì có giảm conflict k bác

Như nhau thôi bạn. Đôi khi rebase còn nhiều conflict hơn vì nó là "replay" lại từng commit một. Tuy nhiên team mình vẫn bắt buộc mọi người phải dùng rebase cho các feature branch để commit của cùng một feature sẽ liền mạch, nhìn history đẹp hơn, muốn bỏ feature nào ra cũng dễ.

BetterNextTime · 29/8/21

24/7 đã nói:
Mình có case như này:

Feature 1: code xong -> merge vào develop -> chờ QC test

Feature 2: chạy sau, tách branch từ develop (có code của feature 1) -> code xong -> merge vào develop -> QC test done

Khách hàng cần release feature 2 trước thì bác làm thế nào ?

Cái này thực tế không liên quan đến git lắm. Git chỉ là source version control thôi. Release code thì là release source chứ không phải nhất thiết là release cho khách hàng.

Có thể dùng configuration để enable features. Nghĩa là code vẫn trong develop, được compile nhưng trong runtime thì được config để không đụng đến.
https://configcat.com/

tiengdonhoarira · 30/8/21

mickey5007 đã nói:
Nhiều người code chung thì conflict là bình thường. Nhưng có bác nào thấy trường hợp code 1 mình mà cũng conflict chưa )

monster_hunter đã nói:
T tự làm tự hủy lun nè. Làm pet project, code trên pc và laptop. Có đợt code trên laptop quên pull về. Thế là conflict sml.

Sent from Vsmart Active 3 using vozFApp

cũng thế. có 2 laptop, 1 để công ty một ở nhà, để đi làm ko phải mang gì. về nhà có lúc quên pull, khi push thì bị conflict, giải quyết cũng dễ

znvdicrd · 30/8/21

24/7 đã nói:
Mình có case như này:

Feature 1: code xong -> merge vào develop -> chờ QC test

Feature 2: chạy sau, tách branch từ develop (có code của feature 1) -> code xong -> merge vào develop -> QC test done

Khách hàng cần release feature 2 trước thì bác làm thế nào ?

Như bên mình mỗi feature sẽ tạo thành 1 branch riêng nên release feature nào trước thì merge cái đó vào master để release.

Kinh nghiệm của mình không phải chỉ với git mà kể cả các tool khác dùng chung trong team là những chức năng nào lạ/advanced/ít khi dùng, kiểu như cherry pick ... thì khi nên hạn chế sử dụng trong workflow của team, trừ khi gặp trường hợp rất đặc biệt. Có thể mình thạo làm thì thấy rất dễ và nhanh hơn, nhưng vào tay người khác không quen mà phải làm là rất dễ toang. Lúc đấy thời gian tiết kiệm được chẳng bõ với thời gian đi xử lý sự cố.

Lập Trình Viên Gà · 12/7/22

Các bác cho e hỏi tại sao phải cố để git history readable nhỉ ?

Mình làm mấy dự án git history trông như bãi rác, có nghĩa là đầy commit chả có title décription gì mà dự án vẫn chạy ngon nên mình chưa hiểu tác dụng lắm

bribnt · 12/7/22

Lập Trình Viên Gà đã nói:
Các bác cho e hỏi tại sao phải cố để git history readable nhỉ ?

Mình làm mấy dự án git history trông như bãi rác, có nghĩa là đầy commit chả có title décription gì mà dự án vẫn chạy ngon nên mình chưa hiểu tác dụng lắm

để dễ revert, cherry-pick và bisect.

servuskevin · 12/7/22

Mình dùng sourcetree.
Pull lúc nào cũng set option rebase mặc định.
Resolve conflict thông qua Kdiff3 set mặc định trong sourcetree luôn.

berong91 · 13/7/22

Lập Trình Viên Gà đã nói:
Các bác cho e hỏi tại sao phải cố để git history readable nhỉ ?

Mình làm mấy dự án git history trông như bãi rác, có nghĩa là đầy commit chả có title décription gì mà dự án vẫn chạy ngon nên mình chưa hiểu tác dụng lắm

quan trọng ở khâu maintainance sau này nữa, nhất là nếu nhiều branch sau này sửa rất là cực nếu lỗi. Ngoài ra còn 1 mớ thứ như Conventional commits, cách đặt tên commit, v.v.

Nhiều dự án mình làm cực đoan tới nỗi bắt linear history luôn, muốn merge gì phải tự rebase tự test, khi nào ổn hết mới được merge.

Mr.Cigar ⠀ · 13/7/22

Lập Trình Viên Gà đã nói:
Các bác cho e hỏi tại sao phải cố để git history readable nhỉ ?

Mình làm mấy dự án git history trông như bãi rác, có nghĩa là đầy commit chả có title décription gì mà dự án vẫn chạy ngon nên mình chưa hiểu tác dụng lắm

Có nhiều dự án nó release = cherry pick thì cái này mới có tác dụng. Còn ko thì đúng là mất thời gian ae dev.
Nói chung mấy cái best practices này nọ lúc nào cũng có 2 mặt thôi ko phải lúc nào cũng tốt hoàn toàn.

hardcoreholly · 13/7/22

Bình thường toàn dùng VS, có sẵn built in luôn, dễ xài. Còn ko thì dùng Tortoise Git

nthemanh · 13/7/22

Lập Trình Viên Gà đã nói:
Các bác cho e hỏi tại sao phải cố để git history readable nhỉ ?

Mình làm mấy dự án git history trông như bãi rác, có nghĩa là đầy commit chả có title décription gì mà dự án vẫn chạy ngon nên mình chưa hiểu tác dụng lắm

Để history readable thì ko chỉ riêng Git mà dùng thằng nào cũng nên vậy. History rõ ràng, gọn gàng thì dễ pick feature từ nhánh này qua nhánh khác hơn trong trg hợp có nhiều nhánh cho các release khác nhau. Quan trọng nhất là khi có issue thì sẽ nhanh trace ra commit nào gây ra issue hơn, nhiều khi chỉ cần đọc commit message là khoanh vùng đc rồi chưa cần nhìn vào code change trong commit

Lập Trình Viên Gà · 13/7/22

nthemanh đã nói:
Để history readable thì ko chỉ riêng Git mà dùng thằng nào cũng nên vậy. History rõ ràng, gọn gàng thì dễ pick feature từ nhánh này qua nhánh khác hơn trong trg hợp có nhiều nhánh cho các release khác nhau. Quan trọng nhất là khi có issue thì sẽ nhanh trace ra commit nào gây ra issue hơn, nhiều khi chỉ cần đọc commit message là khoanh vùng đc rồi chưa cần nhìn vào code change trong commit

Có thể dự án mình bé nên lịch sử git như cc dự án vẫn chạy tốt

chim sẻ đi nắng · 13/7/22

Lập Trình Viên Gà đã nói:
Có thể dự án mình bé nên lịch sử git như cc dự án vẫn chạy tốt

vầy người ta mới có câu đường dài mới biết ngựa hay, lúc phát sinh issue mới thấy lợi ích của clean history

)

Lập Trình Viên Gà · 13/7/22

các bác cho hỏi có nên dùng git merge fast fw ko nhỉ? Ưu / nhược điểm là gì

Tràng Giang · 13/7/22

XiangLiang đã nói:
Trước dùng TortoiseGit, giờ vẫn dùng GitTortoise

same here . Nếu dùng trên Windown thì rất ổn

skyfall · 13/7/22

chim sẻ đi nắng đã nói:
vầy người ta mới có câu đường dài mới biết ngựa hay, lúc phát sinh issue mới thấy lợi ích của clean history )

Chỗ tôi làm dùng perforce, commit bắt ghi nội dung rất dài gồm hiện tượng, nguyên nhân, giải pháp,... chuyển sang git thấy commit toàn kiểu 1 dòng, vài từ nham nhở vãi

chim sẻ đi nắng · 13/7/22

Lập Trình Viên Gà đã nói:
các bác cho hỏi có nên dùng git merge fast fw ko nhỉ? Ưu / nhược điểm là gì

ưu: simple history, sau này cần tìm commit gây bug dễ hơn
nhược: khó hình dung lịch sử commit hơn, nói chung là không đáng kể

hrbbci · 15/7/22

dùng cơm

Lập Trình Viên Gà · 15/7/22

Có cách nào hạn chế việc thành viên trong team dùng git push force ko các thím

Team mình đ solve conflict mà các bố cứ đẩy lên để mình phải ngồi solve hộ

thắc mắc [Git] dùng gì để giải quyết conflict

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Đã tốn tiền

Senior Member

Senior Member

Senior Member

Senior Member

Member

Senior Member

Member

Senior Member

Senior Member

Đã tốn tiền

Member

Senior Member

Senior Member

Chủ đề tương tự

Thống kê chủ đề

Chia sẻ trang này