Django实战技巧（1）-开发测试生产环境配置切换处理技巧

Django实战技巧（2）-git代码仓分支管理技巧

Django实战技巧（3）-项目配置

• git代码仓中代码的处理流程如下图：
  
  其中：
  Remote即为远端代码仓，即为github或者gitee或者自己搭建的gitlab服务器上创建的代码仓
  Repository，本地的代码仓
  index：暂存区
  workspace：工作区

各个命令的含义：
git add：将工作区代码添加到暂存区
git commit：将暂存区代码提交到本地仓库
git push：将本地仓库代码推送到远端仓库
git fetch：将远端仓库中的代码下载到本地仓库
git merge：将本地仓库代码更新到工作区
git pull：将远端仓库代码直接更新到本地工作区
git 代码仓被称作分布式的理解：
使用git管理代码，每个人的本地都有一个代码仓，说白了其实完全可以没有远端服务器的，如果没有远端代码仓的话，那么共享代码的时候就需要每两个人之间都需要互相推送代码，互相将对方的代码更新到自己本地，为了解决互相推送和更新代码的问题，所以使用了一个公共的远端代码仓，如此每个人只需要都和远端公共的代码仓推送和更新，即做到了代码的同步，这也就很好理解为什么说如果远端服务器挂了，每个人本地代码开发完全不受影响的了，只不过大家暂时先不同步，待远端服务器好了再同步就OK了，或者紧急情况下，两个人可以在远端服务器挂了的情况下互相进行推送和更新从而做到两个人的代码同步

• 代码分支管理的技巧
  如下图演示了正常情况下，分支管理的规范

即：
1、在正常情况下，可以创建一个master和一个dev分支接口，dev表示开发分支，master表示版本发布分支
2、每个开发者从dev分支再拉出自己的分支，在自己的分支上进行特性或者功能的开发，在自己的分支上不断进行commit提交
3、当开发者对一个功能或者特性开发完成后，将自己的分支上一次性合并提交到dev分支，这样dev分支只有每个功能描述的额提交，而开发者更新dev分支后，删掉自己之前的分支，重新从dev拉出一个自己的分支，继续开发下一个功能
4、当规划的一个发布版本的多个功能开发完成后，将dev分支合并提交到master分支，这样master分支只显示每个发布版本级别的提交记录
5、然后每当一个版本发布时，再从master分支拉出一个版本的分支，比如发布 1.1.1 的版本，可以拉出 1.1.x 的分支，用来只合入解决bug的代码，不合新功能

这基本就是比较规范的分支管理技巧，当然可以以此为参考根据实际流程需要做更好的规划