技能篇:git的简易教程
在学校,或许凭借一个人的力量就能负责整个项目的开发到上线。但是在公司,因为项目的复杂性和紧急性,一个项目的往往是由多个人实现,此时就有一个问题,代码提交和代码合并。git和svn,这篇文章来讲讲git的原理和使用
- version版本控制
- git的账号配置
- 创建git仓库
- git的原理
- 文件操作命令
- 分支操作命令
关注公众号,一起交流,微信搜一搜: 潜行前行
version版本控制
- 版本控制(Revision control)是一种在开发的过程中用于对文件、目录或工程等内容的修改历史,方便查看更改历史记录,备份及以便恢复以前版本的技术
- 没有进行版本控制或者版本控制本身缺乏正确的管理,在软件开发过程中将会引入很多问题,如软件代码的一致性、软件内容的冗余、软件开发过程中的并发性、软件源代码的安全性,以及软件的整合等问题
git的账号配置
- 配置名字和邮件地址
创建git仓库
git的原理
- 项目文件(Directory):使用Git管理的一个目录,也就是一个仓库,包含我们的工作区(WorkSpace)和 Git的管理空间(.git)
- 工作区(Workspace):就是平时存放项目代码的地方,一个文件夹而已
- git管理空间(.git):存放Git管理信息的目录,初始化仓库的时候自动创建。里面又包含暂存区(Index/Stage)和 本地仓库(Repository)
- 暂存区(Index/Stage):用于存放你的临时改动信息,保存即将提交到文件列表信息。可用于保存/恢复 WorkSpace 中的临时状态
- 本地仓库(Repository):这里面存放你提交到所有版本的数据。其中HEAD指向最新放入仓库的版本
- 远程仓库(Remote):托管代码的服务器,和本地仓库作用类似,不过它是公共的
状态转移流程
- 未跟踪(Untracked): 此文件仅仅在 workspace 中,但并没有加入到 git 仓库,不参与版本控制。通过 git add 状态变为 Staged
- 文件已经入库(Unmodify): 未修改,即版本仓库中的文件快照内容与 workspace 中完全一致。这种类型的文件有两种变化,如果它被修改,而变为 Modified。如果使用 git rm 移出版本库,则成为 Untracked 文件
- 文件已修改(Modified): 仅仅是修改, 并没有进行其他的操作。通过 git add 可进入暂存 Staged 状态,使用 git checkout 则丢弃修改过,返回到 unmodify 状态,这个 git checkout 即从库中取出文件,覆盖当前修改
- 暂存状态(Staged): 执行 git commit 则将修改同步到仓库中,这时库中的文件和 workspace 文件又变为一致,文件为 Unmodify 状态。执行
git reset branchName fileName
取消暂存。文件状态恢复为 Modified
文件操作命令
查看文件状态
添加文件与目录
移除文件与目录
文件提交 git commit
查看文件状态及历史 git log
git diff 比较差异
git reset 代码回退
- 有时提交了一些错误代码,我们想回滚怎么办,可以使用 git reset 重设置代码版本号。git reset 有三种模式 。soft、mixed、hard
-
--hard 模式
重置 HEAD 在当前分支到某次 commit 时,工作目录里的新改动和已经 add 到 stage 暂存区的新改动会全都消失。工作目录(workspace)、暂存区(index/stage)及本地仓库(repository)重置成目标 commit 的內容,所以效果看起来等同于清空暂存区和工作区 -
--soft 模式
--soft 模式在重置 HEAD 时,会保留工作目录和暂存区中的内容,并把重置 HEAD 所带来的新的差异放进暂存区,保留工作目录(workspace)和暂存区(index/stage)的内容,只让 repository 中的内容和 reset 节点保持一致,原节点和 reset 节点之间的差异变动会放入暂存区中(index/stage) -
--mixed 模式
git reset 如果不加参数,那么默认使用 --mixed 参数。mixed 模式会保留 工作目录(workspace)的內容,但会将暂存区(index/stage) 和 Repository 中的內容重置成 reset 节点一致,因此原节点和 reset 节点之间的差异变动会放入工作目录(workspace)
git revert
- 如果我们想撤销之前的某一版本,但是又想保留 commitId 提交之后的版本
分支操作命令
新建分支
git push
删除分支
分支合并
- git-merge 命令是用于从指定的commit(s)合并到当前分支的操作
- 当产生合并冲突时,该部分会以
<<<<<<<
,=======
和>>>>>>>
表示。在=======
之前的部分是当前分支这边的情况,在=======
之后的部分是对方分支的情况 - 解决完冲突的地方后使用
git add
加入到index中,然后使用git commit
产生合并节点
git pull/git fetch
- git fetch 可以拉取远程仓库的代码
- git pull。它不仅会拉取远程分支,还会合并远端和本地代码,即:git pull = git fetch + git merge
git rebase 合并
- git rebase master 命令会把当前分支 curBranch 里的每个提交(commit)取消掉,并且把它们临时保存为补丁(patch)(这些补丁放到".git/rebase"目录中),然后把 curBranch 分支更新为 master 分支最新提交,最后把保存的这些补丁应用到 curBranch 分支上
- 在 rebase 的过程中,也许会出现冲突(conflict)。 在这种情况,Git会停止rebase并会让你去解决 冲突;在解决完冲突后,用 git add 命令去更新这些内容的索引(index), 然后,你无需执行 git-commit,只要执行
git rebase --continue
- 如果 git rebase master 之后。需要将当前分支 curBranch的代码移到 master。可以再次使用 git merge。此时合并后 master 的提交是一条线性 commit
git tag
- tag 对应某次 commit, 是一个点,是不可移动的。branch 对应一系列commit,是很多点连成的一根线,有一个HEAD 指针,是可以依靠 HEAD 指针移动的。所以,两者的区别决定了使用方式,改动代码用 branch,不改动只查看用 tag
- 创建 tag 是基于本地分支的 commit,而且与分支的推送是两回事,就是说分支已经推送到远程了,但是 tag 并没有,如果要把 tag 推送到远程分支上,需要另外执行 tag 的推送命令