这是一个创建于 3904 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近打算和几个朋友协作一个 Node.js 项目，请教前辈几个问题：
1.我们每个人都需要建一个分支吗？朋友说他们用SVN一个小项目共用一个分支
2.Fork和分支是一个意思吗？
3.WebStorm的Node.js项目都需要.gitignore哪些文件？
谢谢！
1.我们每个人都需要建一个分支吗？朋友说他们用SVN一个小项目共用一个分支
2.Fork和分支是一个意思吗？
3.WebStorm的Node.js项目都需要.gitignore哪些文件？
谢谢！
 |
1
zzNucker 2014-03-28 11:38:16 +08:00  1
SVN共用分支的原因是新开分支代价太大。
Git的话分支的代价可以忽略不计，基本就个指针。所以本地你可以随便开多少分支，要不要推送分支到主干你们可以自己商量。。 你们一起开发的话不需要fork了，直接在同一个repo上搞就行了 .gitignore看自己需要啊，比如数据库配置文件。 |
 |
2
learnshare 2014-03-28 11:41:35 +08:00 1
|
|
3
zzNucker 2014-03-28 11:45:08 +08:00 1
修改一下：“要不要推送分支到远程你们可以自己商量”
比如要不要新建个develop分支一起开发之类的。 |
 |
4
hoogle 2014-03-28 12:13:59 +08:00 via iPhone 1
团队每个人建一个自己的分支， 个人又为自己开发的模块建立分支， 开发完成合到自己分支，再将所有人各自已完成的分支合并到master
|
 |
5
WildCat OP |
 |
6
Sunyanzi 2014-03-28 17:29:51 +08:00 1
我带团队用 git 的时候基本不主张 fork ...
大家都操作同一个 repo ... 我维护几个核心的 branch ... 可以随意增加其他 branch ... 大家各自维护自己的 branch ... 在 review 之后再推到某个核心 branch 上 ... fork 和分支也许是一个意思也许不是 ... 我到现在也不清楚 git 的相关用语该如何翻译 ... 所以一般在谈论 git 的时候我会避免使用「分支」这个词 ... fork 的意思是建立一个新的 repo ... branch 我理解更像在当前 repo 中创建独立的空间 ... 至于 gitignore 哪些文件 ... 在使用中你自然就知道了 ... 一般而言所有会被增加到项目中却不属于这个项目的文件都应该被 ignore 掉 ... |
 |
7
cai314494687 2014-03-28 17:54:58 +08:00 1
可以为项目添加合作人的，然后他有权限push
或者你创建一个组织，然后把他们添加到组织的项目里面 |
|
8
WildCat OP @cai314494687 git@osc好像没找到组织
|
 |
9
yuelang85 2014-03-28 18:40:40 +08:00 1
如果你们每人负责一个模块，几乎没有交集，使用同一个分支就可以。
当然，这个还要看你们开发是否统一，比如一个模块需要开发2星期，而你们其他人1星期，又希望每星期出集成，那么两星期那个就需要开分支了。 不过一般都会细化功能，把所有人的节奏都统一到一星期里 |
|
10
cai314494687 2014-03-28 20:47:55 +08:00
@WildCat 对 git@osc 不熟悉，不知道是否有这个功能，但是 GitHub 是有的。
|
 |
11
finian 2014-03-28 22:41:07 +08:00 1
.gitignore 可以参考这个： https://github.com/github/gitignore/blob/master/Node.gitignore
|
|
12
WildCat OP |
 |
13
a591826944 2014-03-29 00:00:31 +08:00
看看 git flow
|
 |
14
goofansu 2014-03-29 00:09:58 +08:00 1
我参与了一个项目是这样协作的(github)：
1. fork主库，添加主库为upstream 2. 开发功能前到主库提一个issue，因为可能有人已经在开发相同的功能了 3. 开发时，在自己的fork中创建一个branch 4. 在这个branch中进行功能开发，做完以后进行如下步骤，就可以把主库的master合并入你的branch a. git checkout master b. git pull upstream master c. git rebase -i master d. 解决冲突 5. 提交branch到github 6. 使用pull request告诉别人你的功能完成了 7. 如果这个功能还要继续修改，就继续循环第4步，github上的pull request会自动反映这个branch的最新更改，这样大家就能持续review你的代码 8. 确认ok了就由一个人合并你的功能进入主库的master 我觉得这个步骤还是蛮清晰的，仅供参考。 |
 |
15
msg7086 2014-03-29 05:37:58 +08:00 2
@goofansu 说的是fork+PR的模型，对于分布式开源项目开发是挺好的。
@a591826944 说的git flow+PR模型，对于一个团队的比较方便。 start feature开分支写代码，然后push+PR做review，最后merge回develop。 图示： http://jacovanstaden.files.wordpress.com/2011/03/git-flow-feature-branch.jpg |
Select Language