对于源码管理和产品线管理为了避免混乱，应该有个大致的管理方案：
项目名假如为：tj_dj
则产品管理线：（主机）
主分支–master
开发分支–develop-tj_dj
发布分支–release-tj_dj
特性分支(短生命线分支)–f-[特性名]-tj_dj
修复分支–hotfix-tj_dj
轻量级开发情况：（AB机间没有网络）
在各自本机建立环境，本地建立好bare仓库和本地开发仓库。
总体上要求，bare仓库是同名的，但在自己的本地开发仓库中把远程仓库命名个性化。Dell为例:
dell-前缀。
技巧：
bare仓库用来fetch和push的“箱子”，为远程仓库。
使用拷贝方式来和其它机共享bare仓库。
各机器为主工作时，则要使用很多分支技术来merge其它机的进度代码。
多人联合开发情况：
这里就仁者见仁，智者见智了。但是最典型的就是gitflow了。但不是起对了几个分支名就行了。要得其要领。
原则：
master和develop分支是稳定分支，一直存在。
master只允许release和hotfix分支来的merge
develop日常开发
feature上开发功能，功能成熟后合并到develop上
release是从develop上分出来，bug修复后，打上tag后，要同时合并回develop和master
很小的bug修复会则会在hotfix上进行。
1). 首先将远程代码拉取到本地
git clone xxx
git checkout -b develop origin/develop
2).新建feature分支
git checkout -b feature
3).多人在feature上开发，如果中途需要将develop的变更合入feature，所有人需要将本地的代码变更提交到远程
git fetch origin
git rebase origin/feature
git push origin feature
然后由feature负责人rebase develop分支，删除原来feature分支，重新新建feature分支；
git fetch origin
git rebase origin/feature
git rebase develop
git push origin :feature
git push origin feature
这样可以保证feature保持线性变更；
4).feature开发完成后，所有人需要将本地的代码变更提交到远程
git fetch origin
git rebase origin/feature
git push origin feature
然后由feature负责人rebase develop分支，然后将feature分支合入develop，删除feature；
git fetch origin
git rebase origin/feature
git rebase develop
git checkout develop
git merge feature
git push origin :feature
这样可以保证develop保持线性变更，各feature的变更完整可追溯；
5).合入feature后拉出对应的release/feature分支，后续bug修复在release/feature上
git checkout develop
git checkout -b release/feature
release/feature分支的同步合并与feature分支相同
6).release/feature分支bug修复完成后，拉取对应的tag推送远程进行发布
git tag -a v1.0 -m ‘feature发布’
git push origin v1.0
之后将release/feature合入develop分支，然后删除
git rebase develop
git checkout develop
git merge release/feature
git push origin :release/feature
7).发布完成后将release合入master分支，保证master为最新稳定版本（实际操作为发起merge request）