云服务器内容精选

  • 分布式版本控制系统 分布式版本控制系统的特点是每个客户端都是代码仓库的完整镜像,包括项目文件的变更历史。所有数据分布的存储在每个客户端,不存在中央服务器。可能有人会问,公司使用Git分布式存储工具,也有“中央服务器”啊?其实,这个所谓的“中央服务器”仅仅是用来方便管理多人协作,任何一台客户端都可以胜任它的工作,它和所有客户端没有本质区别,如下图所示。 常见的分布式版本控制系统为Git、Mercurial、Bazaar、Bitkeeper。 分布式版本控制系统的优点与缺点如下表所示。 表2 分布式版本控制系统描述 优点 缺点 版本库本地化,版本库的完整克隆,包括标签、分支、版本记录等。 支持离线提交,适合跨地域协同开发。 分支切换快速高效,创建和删除分支成本低。 学习成本高,不容易上手。 只能针对整个仓库创建分支,无法根据目录建立层次性的分支。
  • 分支操作 新建分支 Git新建分支的本质就是创建一个指向最后一次提交的可变指针,所以,Git分支的创建不是复制版本库的内容,仅仅是新建了一个指针,它以40个字符长度SHA-1字串形式保存在文件中。 1 #git branch branchName commitID 基于commitID即某一个全球版本号拉出新分支,如果没有commitID则基于当前分支的HEAD拉出新分支。 例如,新建feature分支,执行的命令为git branch feature,如下图所示。 切换分支 命令如下。 1 #git checkout branchName 例如,切换到feature分支,执行的命令为git checkout feature,如下图所示。 分支合并 无论哪种工作流都会涉及到分支合并(把一个分支中的修改整合到当前分支),主要有两种方法:三方合并(merge) 和衍合(rebase)。通过对同一种场景进行不同操作体会两种合并方法的区别。 场景:master分支新增了C4节点, hotfix分支新增了C3节点,现将hotfix分支合并到master分支: 三方包括hotfix新增节点C3,master新增节点C4,以及两者的共同祖先节点C2。这种合并操作简单,但新增合并节点C5,形成了环形,版本记录可读性差,如下图所示。 12 #git checkout master#git merge hotfix 衍合先将master分支新增节点C4以补丁形式保存在.git/rebase目录中,然后同步hotfix分支最新代码,再应用补丁C4’,如下图所示。 12 #git checkout master#git rebase hotfix 冲突解决 场景一:两个合并分支修改了同一行代码 解决方法: 分析哪种修改方法正确,手动合并。 提交修改。 场景二:文件被重命名为不同的名字 解决方法: 确认哪个名字是正确的,删除错误的。 提交修改。
  • 推送架构代码 打开本地框架代码,确保根目录名与云端创建的代码仓库名一致,在根目录下右键打开Git bash终端。 推送本地代码到云端。 在当前Git Bash终端依次输入如下命令: 初始化本地代码仓库,执行该命令后,在“D:/code/repo1/”下多了一个“.git”文件夹。 1 $ git init 关联云端代码仓库。 1 $ git remote add origin repoUrl 仓库地址如下图进入仓库详情页,单击”克隆/下载“,所示单击红色方框处获取。 推送代码到云仓库。 12345 $ git add . $ git commit -m "init project"$ git branch --set-upstream-to=origin/master master$ git pull --rebase$ git push