[請益] git協同合作問題

看板Soft_Job作者 (灰色老虎)時間2年前 (2021/12/09 13:40), 2年前編輯推噓21(21推 0噓 21→)
留言42則, 24人參與, 2年前最新討論串1/1
遇到一個情境 想請問應該如何操作 假設現在 有一個主分支release 兩個feature branch 第二個分支需要用到第一個分支部分代碼 另外一部分不能弄進來 但是因爲第一個分支還沒回release 但如果選擇了pull merge 第一個分支拉部分的code(如圖紅色的部分） 第二分支回release之後... 第一個分支去pull release的時候會造成檔案被修改或刪掉如圖藍色部分 https://i.imgur.com/hgMRn5l.jpg
紅色那塊該怎麼做呢？才不會影響到藍色部分的代碼 是不是應該pull 完第一個分支之後reset ? -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 211.75.111.130 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1639028434.A.680.html ※ 編輯: greytiger (211.75.111.130 臺灣), 12/09/2021 13:43:36
推
12/09 13:53, 2年前 , 1F
手動編輯將codeB 的修改搬到 BranchB，或 cherry-pick 試
12/09 13:53, 1F
→
12/09 13:53, 2年前 , 2F
試？
12/09 13:53, 2F
推
12/09 13:54, 2年前 , 3F
你可以cherry pick
12/09 13:54, 3F
→
12/09 13:55, 2年前 , 4F
Cherry pick Code B 的 commit
12/09 13:55, 4F
Cherry pick 要的每一個commit嗎～ ※ 編輯: greytiger (211.75.111.130 臺灣), 12/09/2021 14:09:03
推
12/09 14:41, 2年前 , 5F
chrry pick阿，不然就merge 再 revert 不要的 commit
12/09 14:41, 5F
推
12/09 15:07, 2年前 , 6F
撿櫻桃很好用的
12/09 15:07, 6F
推
12/09 15:19, 2年前 , 7F
避免用revert 到時候merge A的時候會有問題
12/09 15:19, 7F
推
12/09 16:06, 2年前 , 8F
cherry-pick
12/09 16:06, 8F
→
12/09 16:14, 2年前 , 9F
對 你可以先cherry pick 好幾個回來 然後都不要 commi
12/09 16:14, 9F
→
12/09 16:14, 2年前 , 10F
t
12/09 16:14, 10F
推
12/09 16:56, 2年前 , 11F
我沒想到mergeA，失策了
12/09 16:56, 11F
推
12/09 19:50, 2年前 , 12F
rebase -i 選你要的
12/09 19:50, 12F
推
12/09 19:52, 2年前 , 13F
commit很多用rebase 一兩個commit 用chrry pick
12/09 19:52, 13F
請問rebase 怎麽操作呢 小弟只有用過rebase release 和rebase 改commit 沒有在feature branch rebase 其他的feature branch過 如果選用squash merge 還會出現藍色的那種狀況？ 1. 如果 在B 分支 squash merge 分支A 2. B PR回release 用 squash merge進去 這樣還會有藍色狀況嗎？ ※ 編輯: greytiger (42.72.113.67 臺灣), 12/09/2021 21:37:37
→
12/09 21:49, 2年前 , 14F
我會用不是git的方法解決它 做的事情愈來愈多 愈來愈
12/09 21:49, 14F
→
12/09 21:49, 2年前 , 15F
不符合類unix邏輯了
12/09 21:49, 15F
推
12/09 22:17, 2年前 , 16F
試試 git checkout --patch target_branch file/path
12/09 22:17, 16F
→
12/09 22:17, 2年前 , 17F
--patch可以只checkout 一部分的code, 我還蠻常用的
12/09 22:17, 17F
推
12/10 01:58, 2年前 , 18F
rebase啊 萬用解
12/10 01:58, 18F
→
12/10 01:58, 2年前 , 19F
只要你可以聯絡道寫branch的人就可以當場解衝突
12/10 01:58, 19F
推
12/10 11:55, 2年前 , 20F
就多開一個分支當緩衝就好拉
12/10 11:55, 20F
推
12/10 11:59, 2年前 , 21F
這種情況 我不會在作業branch直接merge/rebase/撿櫻桃
12/10 11:59, 21F
→
12/10 12:00, 2年前 , 22F
另外開一個branch去處理 在發mr給自己檢查 會比較安全
12/10 12:00, 22F
推
12/10 19:38, 2年前 , 23F
rebase -i根本是神器
12/10 19:38, 23F
推
12/11 09:39, 2年前 , 24F
會用git當版控的聖盃通常邏輯不是很強,會在這鬼異的死循
12/11 09:39, 24F
→
12/11 09:40, 2年前 , 25F
環一直無限循環下去,會一直上來po文問,又解決不了問題
12/11 09:40, 25F
→
12/11 09:41, 2年前 , 26F
唯一的解法是:幹掉產生問題的工具-->git. 不能再多說了
12/11 09:41, 26F
→
12/11 09:42, 2年前 , 27F
懂的就懂，不懂的就一輩子一直詭異下去吧
12/11 09:42, 27F
推
12/11 16:40, 2年前 , 28F
飢餓遊戲git開發者的惡趣味若權責沒分配好加班加到爆~
12/11 16:40, 28F
推
12/11 22:22, 2年前 , 29F
推樓上，我公司技術魔人一直在推，結果搞到最後難看收拾
12/11 22:22, 29F
→
12/13 15:56, 2年前 , 30F
其實git真的滿囉嗦 但沒辦法大家都用
12/13 15:56, 30F
→
12/14 23:19, 2年前 , 31F
敢問前幾樓有什麼更好的版控工具？
12/14 23:19, 31F
→
12/14 23:19, 2年前 , 32F
可以分享一下嗎？
12/14 23:19, 32F
推
12/15 08:28, 2年前 , 33F
有時候覺得git不好用是開發流程沒那個需求。當有一堆要分
12/15 08:28, 33F
→
12/15 08:28, 2年前 , 34F
階段上版的功能待測試，同時又有產品要fix bug更新，沒有gi
12/15 08:28, 34F
→
12/15 08:28, 2年前 , 35F
t配合ci/cd還不知道要怎麼測。
12/15 08:28, 35F
推
12/15 18:55, 2年前 , 36F
是說 release當主幹道是認真的嗎
12/15 18:55, 36F
推
12/16 13:57, 2年前 , 37F
我個人想不到比git還強大的版控就是了QQ
12/16 13:57, 37F
→
12/16 14:02, 2年前 , 38F
然後樓上大大的推文才讓我想到 如果有個dev branch 然後
12/16 14:02, 38F
→
12/16 14:02, 2年前 , 39F
用force push/merge/cherry-pick去控制release branch是
12/16 14:02, 39F
→
12/16 14:02, 2年前 , 40F
不是會比較好 整個結構應該有優化空間
12/16 14:02, 40F
推
12/16 18:10, 2年前 , 41F
除了Git 還有什麼好用的版控呀？
12/16 18:10, 41F
→
12/16 21:13, 2年前 , 42F
同問，如果開發流程很複雜，還有哪套比 git 好用？
12/16 21:13, 42F
‣ 更多 greytiger 的文章
文章代碼(AID): #1XiPRIQ0 (Soft_Job)