Pycharm中使用Git_pycharm git stash

Pycharm中使用Git

1.使用Git私服创建cmdb项目版本库

• 在服务上注册用户后登陆
  

• 填写厂库信息
  

• 添加本地ssh密钥
  

• 获取远程仓库地址：git@192.168.61.108:xdd/mumuxi.git

• 使用pycharm创建一个项目
  

• 选择项目目录，填入远程版本库地址git@192.168.61.108:xdd/mumuxi.git，Test测试一下
  

• 在项目中新建一个python文件
  

• 编写代码：

if __name__ == "__main__":
    print("hello word")
1
2

• 提交代码
  

• 填写提交信息(这里可以选择提交或提交并推送。本次选择提交)
  

• 提交到远程厂库(vcs->git->push)
  
  

• 提交成功后可以查看远程仓库中的变化：
  

暂存stash

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

class Dispatcher:
    cmds = {}
    def reg(self,cmd,fn):
        pass
    def run(self):
        pass
1
2
3
4
5
6

• commit提交一下后，并完善分发器代码

class Dispatcher:
    cmds = {}
    def reg(self,cmd,fn):
        self.cmds[cmd] = fn

    def run(self):
        pass

    def defaultfn(self):
        print("Unknown Command")
1
2
3
4
5
6
7
8
9
10

• 这时候发现text.py急需完善代码，但是分发器模块还没有完成不想提交。这时候讲究需要stash了。
  
  
• 执行完成，可以看到工作区回到了上次提交的样子。修改急需修改的文件test.py修改完成后提交。
  
  
• 提交急需修改的文件

• 完成后unstash pop恢复刚才完成一半的文件。

• 恢复后可以看到，紧急修复的文件还在。而之前临时保存的文件已经恢复了。(dispatcher.py文件又变成了刚才修改过的样子，继续完成代码，提交。 )

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

分支branch

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

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

分支名

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

单分支

• 图中绿色节点表示每一次提交commit
  项目往往是并行多人开发的，都在主分支上克隆，然后修改提交，那么主分支就会有存在大量的冲突。甚至有一些 不完善代码提交，主分支就混乱不堪，不可维护了。

多分支

创建分支
需要指明从什么分支上创建什么名字的分支。版本控制的Log标签页

• 在最后最后一次提交分支上用鼠标点击右键，创建NewBranch…新的分支

• 到目前就在master上拉出一个分支并切换到了这个新的分支dev上开发，修改test.py，后并提交
  

• push到服务器看看

• 可以看到服务器上已经多出一个分支
  

合并分支

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

• 在log中，选中master最后一次提交的分支，鼠标右键Brach 'master'-->checkout检出分支，切换到master分支
  

• 检出后可以看到项目回到了master分支时的内容，pycharm中的log分支显示master分支亮起了黄牌。
  

• 开始合并，VCS->Git->Merge Changes..
  
  

• 合并后可以看到本地master分支发生的变化。(注意：合并后需要push才能提交的远程服务器。)
  

• 将合并结果push到远程服务器。

以此内推，可以继续检出dev分支，继续开发，开发好了，合并进master分支。这样可以保证master分支的提交清洁度

Fast Forward合并

• 从前面操作的图中可以看到，默认No FF不勾选的，也就是默认使用FF方式合并。
• no-ff的好处是，可以看清楚开发分支上的代码改动。

上面dev分支总是开发中的代码，dev测试、审查后合并到master中。
master分支都是稳定的代码，可以发布部署。

GitFlow工作流

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

1. 最佳实践
   • 使用Git一般至少2个分支：master和develop
   • master，主干，生产环境都来主干分支上拿数据部署，也可以使用钩子自动完成
   • develop，开发分支，开发人员都是检出这个分支开发
2. 辅助分支
   • feature 分支，具体的功能开发分支，只与 develop 分支交互。
   • release 分支，发布版本
   • hotfix 分支，紧急bug修复的版本，后需要合并到develop 和 master中。

• 多分支结构图