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

  • Người tạo chủ đề Người tạo chủ đề tiengdonhoarira
  • Ngày bắt đầu Ngày bắt đầu
Mesh tức là gộp nhiều commits nhỏ vô làm 1 cái to để đỡ phải resolve liên tục khi rebase đó fen, cách ae nói với nhau hàng ngày thôi chứ ko phải là câu lệnh của git
Q8sGcLO.png
Gộp bằng cách nào thế. Chắc cũng dùng git squash chứ? Hay lại reset rồi commit all in one :shame:
 
như tiêu đề, khi git merge có conflict mọi người dùng chương trình gì, hay cách gì, để merge nó


mình thì dùng jetbrain. khi có conflict, sẽ mở ra cửa sổ merge, chọn file để merge, sẽ mở ra cửa sổ có 3 cột, our version, final version, their version. merge vô final rồi chọn apply

bạn mình dùng vim. nhưng ko hiểu nhìn git diff nhận ra ntn
Github desktop là đủ
HLnSsLD.png
 
Squash chỉ là 1 câu lệnh chứ đâu phải cách duy nhất đâu fen, git reset cũng đc nếu commit msg vô nghĩa. Mình gọi chung là mesh
3p4UF0J.gif
Cái từ mesh nó chẳng có ý nghĩa gì trong hoàn canhr này. Git reset cũng chẳng liên quan đến vấn đề “gộp commit” luôn. Fen cứ tung buzzword vào để tỏ ra thượng đẳng thế nhở.
 
Cái từ mesh nó chẳng có ý nghĩa gì trong hoàn canhr này. Git reset cũng chẳng liên quan đến vấn đề “gộp commit” luôn. Fen cứ tung buzzword vào để tỏ ra thượng đẳng thế nhở.
Tôi nói hàng ngày như nào thì tôi gõ ra như vậy thôi fen, buzzword phải là mấy từ nói phát ai cũng biết chứ
uq1dgnk.png

Combo git reset --soft HEAD~x + push force gộp trash commits bt nhé sao lại không liên quan?
 
Tôi nói hàng ngày như nào thì tôi gõ ra như vậy thôi fen, buzzword phải là mấy từ nói phát ai cũng biết chứ
uq1dgnk.png

Combo git reset --soft HEAD~x + push force gộp trash commits bt nhé sao lại không liên quan?
À cái này lỗi mình, chưa hề dùng git reset theo hướng ấy. Thanks fen :*
 
lần đầu tiên nghe đến cái từ "git mesh", đếch biết phải hiểu nó như nào
còn cái vụ tạo nhiều commit, ai đủ thông thạo git thì cứ dùng amend commit là hay nhất, đơn giản
 
Fork, source tree, vs code, rùa :shame:

Gửi từ Xiaomi Redmi Note 4 bằng vozFApp
 
Có thím nào resolve khi merge 2 repository khác history chưa :v

via theNEXTvoz for iPhone
Ca này đúng khó luôn nếu bắt buộc phải giữ history của cả 2 respo. Đầu tiên phải pull --allow-unrelated-histories trước thì phải, sau đó mọi rắc rối cũng từ đây, nhất là mấy file được rename hoặc đổi path thì ôi thôi khóc cmnl.

còn trường hợp ko cần giữ history của 1 repo thì cứ copy dán qua rồi xem lại nội dung từng file. Cơ mà nói chung vẫn quá là khoai đi
 
Ca này đúng khó luôn nếu bắt buộc phải giữ history của cả 2 respo. Đầu tiên phải pull --allow-unrelated-histories trước thì phải, sau đó mọi rắc rối cũng từ đây, nhất là mấy file được rename hoặc đổi path thì ôi thôi khóc cmnl.

còn trường hợp ko cần giữ history của 1 repo thì cứ copy dán qua rồi xem lại nội dung từng file. Cơ mà nói chung vẫn quá là khoai đi
Tất cả các trường hợp merge hoặc cherry-pick 2 repo ko chung history đều sẽ bị reject hết. Nên phương án là 1 bên sẽ bị mất history, cái này buộc phải chấp nhận.

Sau đó tôi gộp tất cả 1 bên thành 1 commit (trên đỉnh cây git reset mềm về gốc), tức là nó phân biệt đc update (có update) trên từng file. Sau đó thì có thể cherry pick cái commit tổng này sang bên kia.

Giờ đến đoạn resolve (cỡ đâu đó vài trăm file thôi) :rolleyes:
Khi resolve thì tuỳ kinh nghiệm dev, nếu nắm bắt tốt sự thay đổi thì tốc độ resolve cũng ko quá mất time.
 
bình thường project các bác xài merge hay rebase nhỉ?
bên em thì chỉ xài merge thôi để lun track được history của các commit. ngay cả khi conflict thì cũng clone ra 1 nhánh và merge no-ff vào nhánh chính:p

mà có 1 cái rất là dễ gây conflict đó là hay chơi cái trò cherry-pick.:beat_shot::beat_shot:
cherry-pick vào master để hotfix các features nên khi merge code của features mới thì rất dễ gây conflict
 
bình thường project các bác xài merge hay rebase nhỉ?
bên em thì chỉ xài merge thôi để lun track được history của các commit. ngay cả khi conflict thì cũng clone ra 1 nhánh và merge no-ff vào nhánh chính:p

mà có 1 cái rất là dễ gây conflict đó là hay chơi cái trò cherry-pick.:beat_shot::beat_shot:
cherry-pick vào master để hotfix các features nên khi merge code của features mới thì rất dễ gây conflict
Merge thôi, tuy nhiên history sẽ hơi rối nếu nhiều branch, cơ mà vẫn chấp nhận được,còn rebase không biết xài thì khá nguy hiểm, nhất là mấy ông chưa có kinh nghiệm git :D
 

Thống kê chủ đề

Ngày tạo
tiengdonhoarira,
Người trả lời cuối
chim sẻ đi nắng,
Trả lời
185
Lượt xem
19.944
Quay lại
Lên đầu trang