Pycharm中使用Git
- Git私服创建cmdb项目版本库
- 项目开发
- 1. 添加app.py文件
- 2. 编写源码 app.py
- 3. 第一次提交
- 4. push到Git服务器
- 存储stash
- stash
- 应用场景
- 分支branch
- 单分支
- 分支名
- 多分支
- 创建分支
- 修改 app.py,之后提交
- push到私服
- 合并分支
- Fast Forward 合并
- no-ff的好处
- GitFlow工作流
- 最佳实践
- 辅助分支
Git私服创建cmdb项目版本库
- 获得远程仓库地址
git@192.168.142.135:my/cmdb.git
如有必要,添加密钥 - 从版本控制工具中获取项目,选择Git
- 选择项目目录,填入远程版本库地址,Test测试一下
- 成功,并直接用Pycharm打开项目。
项目开发
1. 添加app.py文件
- 提示是否加入到git
2. 编写源码 app.py
if __name__ = "__main__":
print("helle world")
3. 第一次提交
- 这里可以选择提交,或提交并推送
- 本次选择提交
4. push到Git服务器
- 成功push。
- 私服查看
命令 | 说明 |
| 暂时存储最后一次提交后的变化,放入栈中 |
| 从栈中取出刚才保存的变化,并合并 |
- 增加一个新的文件并再次提交
dispatcher.py
# dispatcher.py
class Dispatcher:
cmds = {}
def reg(self, cmd, fn):
pass
def run(self):
pass
- commit提交一下后,开始完善分发器代码
class Dispatcher:
cmds = {}
def reg(self, cmd, fn):
self.cmds[cmd] = fn
def run(self):
pass
def defalutfn(self):
ptint('Unknown Command')
- 这时候发现app.py急需完善代码,但是分发器模块块没有完成不想提交,这时候就需要stash了。
stash
- 执行完,工作区回到了上次提交的样子,回到app.py中完成修改,最后提交。
if __name__ =='__main__':
print('Welcom to www.baidu.com')
上图左图显示区为修改前的代码,右边为修改后的代码
unstash pop
刚才存储的dispatcher.py文件dispatcher.py文件又变成了刚才修改过的样子,继续完成代码,提交。
应用场景
- 开发中,当前手中的工作没有完成,需要中断当前工作来完成其他请求,例如修复Bug。
- 已完成的工作内容提交不合适,可能还要需要大的调整,但是紧急请求又不能不做,就需要stash存储未完成的工作(上次提交后做的修改)。
注:以下的操作都在Pycharm中完成,其它IDE都可以实现类似的功能
- 多人协作一起开发,开发项目中不同的独立的功能,这些功能可能需要好几天才能完成, 又或者定制版本,往往需要一个不同的定制需求。
- 代码中至少有一个分支,就是主干分支或称主分支Master,默认都是在主分支上开发。
单分支
- 图中绿色节点表示每一次提交commit
- 项目往往是并行多人开发的,都在主分支上克隆,然后修改提交,那么主分支就会有存在大量的冲突。甚至有一些 不完善代码提交,主分支就混乱不堪,不可维护了。
- 再一个,如果一次提交后,需要发布一个版本,这个版本以后需要独立维护、开发,而主分支还需要继续发展,怎 么办?
- 引入多分支
- 分支名在版本库中必须唯一
- 不能以
-
开头 - 可以使用
/
,但是不能以它结尾,被它分割的名称不能以.
开头 - 不能使用两个连续的
..
- 不能包含任何空白字符、Git的特殊符号
- 注: 分支名一般要么叫
Master
要么叫dev
创建分支
- 需要指明从什么分支上创建什么名字的分支。版本控制的Log标签页
- 到目前就在master上拉出一个分支并切换到了这个新的分支dev上开发
修改 app.py,之后提交
from dispatcher import Dispatcher
if __name__ == "__main__":
print('Welcom to www.baidu.com')
dis = Dispatcher()
dis.run()
push到私服
合并分支
- dev开发告一段落,需要将功能合并入master。 切换回到master,检出master
- 开始合并,选择No Fast Forword合并
- 目前的合并,只是本地,需要push到远程库
- 当然还可以继续检出dev分支,继续开发,开发好了,合并进来
- 从前面操作的图中可以看到,默认NoFF不勾选,也就是默认使用FF方式合并。
no-ff的好处
- 可以看清楚开发分支上的代码改动。
上面dev分支总是开发中的代码,dev测试、审查后合并到master中。 master分支都是稳定的代码,可以发布部署。
GitFlow工作流- 不同公司,不同的项目规模,不同的管理水平都有着不同Git工作流方式
最佳实践
- 使用Git一般至少2个分支:master和develop
master,主干,生产环境都来主干分支上拿数据部署,也可以使用钩子自动完成
develop,开发分支,开发人员都是检出这个分支开发
辅助分支
feature 分支,具体的功能开发分支,只与 develop 分支交互。
release 分支,发布版本
hotfix 分支,紧急bug修复的版本,最后需要合并到develop 和 master中。