其实，做人最怕的不是努力了没结果，而是还没尝试就选择放弃。想一千次，不如去做一次，你不逼自己一把，怎会知道自己有多优秀。与其抱怨，不如改变。你若不成长，谁来替你坚强！

总结：

1. 做项目肯定就是模块化；都必定要使用版本管理工具Git；
2. . 开头的都是特殊文件；
3. 大多数企业都是两条分支开发；分支越多，不一定管理的了；

1. 从本地windows生成git ssh密钥

记得安装过程中要添加一个git.exe文件，这个文件在上一个安装文件的路径下面

从程序目录启动“Git Bash”，输入 生成密钥；

# "email@email.com"是你的github账号
ssh-keygen -t rsa -C "email@email.com"

你的C:\Users\admin.ssh这个路径下会生成两个文件：id_rsa和id_rsa.pub
记事本打开id_rsa.pub文件，复制内容，在github.com的网站上到ssh密钥管理页面，添加新公钥，随便取个名字，内容粘贴刚才复制的内容。

增加密钥

2. Pycharm中使用Git

Pycharm中建立cmdb项目连接
从版本控制工具中获取项目

选择项目目录，填入远程版本库地址，Test测试一下；

3. 项目开发实例；

提交、推送项目；

私服查看项目推送；

存储stash

急需完善代码，但是分发器模块没有完成不想提交，这时候就需要stash了；

应用场景

开发中，当前手中的工作没有完成，需要中断当前工作来完成其他请求，例如修复Bug。
已完成的工作内容提交不合适，可能还要需要大的调整，但是紧急请求又不能不做，就需要stash存储未完成的工作（上次提交后做的修改）。

增加一个新的文件并再次提交dispatcher.py

上一次提交其他文件有个小问题需要修改；stash上一次后修改；

修复后提交需要再次说明

返回最上一次修改的状态；并弹出pop stash(选择保留还是不保留)保留的数据;

还原的数据

gogs查看提交历史

GUI查看提交历史；

分支branch

注：以下的操作都在Pycharm中完成，其它IDE都可以实现类似的功能，Git命令操作较为麻烦，不再演示

多人协作一起开发，开发项目中不同的独立的功能，这些功能可能需要好几天才能完成，
又或者定制版本，往往需要一个不同的定制需求。
代码中至少有一个分支，就是主干分支或称主分支Master，默认都是在主分支上开发。

单分支

图中绿色节点表示每一次提交commit

项目往往是并行多人开发的，都在主分支上克隆，然后修改提交，那么主分支就会有存在大量的冲突。甚至有一些不完善代码提交，主分支就混乱不堪，不可维护了。
再一个，如果一次提交后，需要发布一个版本，这个版本以后需要独立维护、开发，而主分支还需要继续发展，怎么办？引入多分支；

分支名 规则：
分支名在版本库中必须唯一；
不能以 - 开头；
可以使/,但是不能以它结尾，被它分割的名称不能以 . 开头；
不能使用两个连续的..
不能包含任何空白字符、Git的特殊符号；

多分支
创建分支dev

合并分支

dev开发告一段落，需要将功能合并入master。
切换回到master，检出master

目前的合并，只是本地，需要push到远程库；

从前面操作的图中可以看到，默认No FF不勾选的，也就是默认使用FF方式合并。
no-ff的好处是，可以看清楚开发分支上的代码改动。
上面dev分支总是开发中的代码，dev测试、审查后合并到master中。
master分支都是稳定的代码，可以发布部署。

GitFlow工作流

不同公司，不同的项目规模，不同的管理水平都有着不同Git工作流方式。

最佳实践
使用Git一般至少2个分支：master和develop
master，主干，生产环境都来主干分支上拿数据部署，也可以使用钩子自动完成
develop，开发分支，开发人员都是检出这个分支开发

辅助分支
feature 分支，具体的功能开发分支，只与 develop 分支交互。
release 分支，发布版本
hotfix 分支，紧急bug修复的版本，最后需要合并到develop 和 master中。

大多数企业都是两条分支开发；分支越多，不一定管理的了；

打标签一般在主分支上打标签，很少有在侧分支上做标签；