likes
comments
collection
share

深入 Git 和开发规范

作者站长头像
站长
· 阅读数 6

文中内容部分参考来源:《GitHub 入门与实践》——【日】大塚弘记

使用 Git 会给开发带来哪些变化?

Git 的出现使得当今世界的软件开发带来了翻天覆地的变化。此前大部分的协同工作软件逐渐退出历史舞台,Git 工作流上位,变革了团队开发的协作方式。

能看到更多其他团队的软件

Git 并不局限于开发团队内部使用,只需要将仓库添加 watch ,就可以跟踪项目进度,看到别的团队每天都在开发什么功能。如果可以,你还可以进一步交流,分割公用的库,或者参与到项目开发,相互优化,成了不同开发者团队间协作的美谈。

社会化编程(Social Coding)

Git 的出现,为开源世界带来了社会化编程的概念,软件开发者因此拥有了真正意义上的源代码,世界上任何人都可以比以前更加容易的获取源代码,将其自由更改并加以公开。

在 类似 GitHub 的平台出现之前,软件开发中只有一小部分人拥有更改源代码的权利,这个特权阶级掌握着开发的主导权。开发者在改写、发布源代码之外,往往需要花更多时间和精力去说服这个特权阶级。这导致了许多起初效率很高的流行软件越发保守化,最终被时代所抛弃。

但是,GitHub 的出现为软件开发者的世界带来了真正意义上的“民主”,让所有人都平等地拥有了更改源代码的权利。这在软件开发领域是一场巨大的革命。而革命领导者 GitHub 的口号便是“社会化编程”。

为什么需要社会化编程

当今的 IT 业界已经没有了终身雇佣制,人才流动性日益增大。可以说,每个月我们都能在一些著名开发者的博客中看到这种现象: 月末刚发布“辞职了”的消息,月初就又“入职了”。

您是程序员的面试官,两者之间您会选择哪一位呢?

能查看到以前所写代码的程序员 or 无法查看的程序员 精通最新软件的程序员 or 不精通的程序员 对语言或软件差异带来的不同文化有所理解的程序员 or 不理解的程序员

为了不成为后一种程序员,理解社会化编程至关重要。

除了 Git 三连,实际工作中还有哪些常用操作

如果你平时使用命令行提交代码,那么一定很熟悉 Git 三连:

git add . // 向暂存区添加文件

git commit -m 'xxx' // 保存仓库历史记录

git push // 推送更改到远程

git log--查看历史提交日志

git log命令可以查看以往仓库中提交的日志, 包括可以查看什么人在什么时候进行了提交或合并,以及操作前后有怎样的差别。

只显示提交信息的第一行:

git log --pretty=short

显示文件的改动:

git log <file>

查看文件更改前后的差别:

git diff

git branch--显示分支一览表

branch 命令可以将分之名以列表的形式展示,同时可以确认当前所在的分支名

查看远程分支列表:

git branch -a

git checkout--创建、切换分支,放弃本地修改

checkout 命令在分支操作上经常使用,同时支持本地文件的操作

创建并切换到新分支:

git checkout <branch> // 切换到分支

git chekcout - // 切换到上一次使用的分支

git checkout -b <branch> // 创建并切换

放弃某个文件的修改:

git checkout <file>

git checkout . // 放弃所有文件修改

git reset--回退历史版本

Git 的另一特征便是可以灵活操作历史版本。借助分散仓库的优势,可以在不影响其他仓库的前提下对历史版本进行操作。

回退到某个历史提交:

git reset <commit> // 回退到某个版本,不回退文件
git reset --hard <commit> // 回退到某个版本,并回退文件

git merge--合并分支

当开发到一定程度后,需要将开发分支的代码合并到测试或者主干分支,这时候,需要用到 merge 命令。

git merge <branch> // 合并某个分支到当前分支

git pull 的时候,发生了什么?

很多人不理解 Git 的拉取pull和获取fetch的区别,其实当执行 git pull 的时候,经历了两个步骤,一个是获取fetch,并自动合并merge

而获取则支持单纯的执行fetch,并不会自动合并。

如下例子:

git fetch origin master:temp //从远程仓库 master 获取,并建立本地分支 temp

git diff temp //对比修改

git merge temp //合并tmp

修改了文件,突然发现分支不对,怎么办?

有时候当我们修改了文件后发现,分支忘了切回开发分支了,除了笨笨的复制文件,然后切换回正确分支,再恢复代码,还有更好的操作吗?

执行 git stash 暂存修改到缓存后,切换到正确分支,并将修改出栈:

git stash // 暂存修改

git checkout <branch> // 切换分支

git stash pop // 将修改出栈(恢复)

Git分支管理规范

master 主分支

作为正式环境分支(稳定版),只读,不可修改,可被merge 正式服务器应当切换为此分支

release 预发布分支

作为验收环境分支,不可修改,可被merge 验收或正式服务器上线前应当切换为此分支

develop 测试分支

作为测试环境分支,可修改,可被merge 测试服务器应当切换为此分支

feature/ 开发(功能)分支

作为开发环境分支,本地开发和开发服务器应当切换为此分支

深入 Git 和开发规范

hotfix/ 修复BUG分支

作为修复BUG分支,应从线上或测试分支拉取一个hotfix分支,BUG解决后merge到测试或线上分支

深入 Git 和开发规范

Git工作流模型推荐

深入 Git 和开发规范