請(qǐng)問(wèn)前輩，像github，碼云這種平臺(tái)，多人合作開(kāi)發(fā)同一個(gè)項(xiàng)目的操作到底是怎樣的？？？

https://git-scm.com/book/zh/v2

這本書(shū)還可以。新手更要看書(shū)，不然出錯(cuò)次數(shù)太多了。

https://laravel-china.org/art...

來(lái)看看這篇文章，gitflow 工作流

git的多人協(xié)作使用有各種方式，可以參考gitflow流程（根據(jù)參與開(kāi)發(fā)人數(shù)與項(xiàng)目復(fù)雜度可以適當(dāng)簡(jiǎn)化流程）

同名文件夾不會(huì)有覆蓋，會(huì)合并文件夾。

同名文件也不會(huì)覆蓋，首先git會(huì)掃描文件改動(dòng)，嘗試執(zhí)行合并（merge）。
如果不能自動(dòng)合并，會(huì)提示你文件沖突（conflict），此時(shí)后來(lái)者pull后需要手動(dòng)編輯文件查看雙方修改，處理完沖突并commit，然后再push。
如果可以自動(dòng)合并，也要注意極特殊情況下可能出現(xiàn)錯(cuò)誤的自動(dòng)合并，因此需要做好測(cè)試工作。

一般協(xié)作的時(shí)候沒(méi)有分這么細(xì)的，一個(gè)人寫(xiě)上半段，一個(gè)人寫(xiě)下半段，而是每個(gè)人各自負(fù)責(zé)一個(gè)模塊/文件夾，公共的部分也是指定其中一個(gè)人單獨(dú)負(fù)責(zé)，這樣在合并的時(shí)候就不會(huì)有沖突，如果非要在同一個(gè)模塊或文件上共同操作，就要采用各自編寫(xiě)分支，最后再合并的策略了，但是這種情況我一般會(huì)避免，因?yàn)榻鉀Q沖突往往比較費(fèi)事，也容易出錯(cuò)，分支多了也很難管理，如果項(xiàng)目規(guī)模不大，沒(méi)必要這么折騰。

再補(bǔ)充一句，如果真的有一個(gè)人寫(xiě)上半段，一個(gè)人寫(xiě)下半段的情況，那你要看一下是不是在項(xiàng)目的組織與分割上出了什么問(wèn)題，這個(gè)文件/模塊是不是需要被進(jìn)一步分割。

你不是不了解github，你是不了解git

你去看一下Git，Git可以解決你描述的問(wèn)題。你們?cè)谕粋€(gè)分分支開(kāi)發(fā)就可以了，然后你同事把改完的代碼提交到遠(yuǎn)端，你pull下來(lái)就可以了，如果出現(xiàn)沖突了，解決一下就好，你再push你的代碼到遠(yuǎn)端，你同事再pull下，這樣代碼就可以相互依賴(lài)使用，而不會(huì)出現(xiàn)你說(shuō)的覆蓋的問(wèn)題

兄弟,如果是這樣,我這里有一些進(jìn)階的git的東東.常用的git用來(lái)做管理哈,其中有branch開(kāi)發(fā),issue就是問(wèn)題,也可以設(shè)置里程碑來(lái)進(jìn)行開(kāi)發(fā),可能用的很多的就是用branch開(kāi)發(fā),用tag來(lái)申明版本.
像普通的,一般就把git當(dāng)成svn來(lái)用.完全提現(xiàn)不了git的魅力.
給你一本天殘劍法,哈哈,看不懂哈,
其實(shí)還有一本九陽(yáng)神功.
額,加班去了.....

多update,多commit，有沖突就merge，完事兒

最好要有一個(gè)分支，代碼提交在分支上，剛開(kāi)始創(chuàng)建的項(xiàng)目一般是在master上，有沖突的話(huà)可以merge，rebase等操作，這些在需要去學(xué)習(xí)下，不難

說(shuō)的是github的pull request功能吧。