Git常用操作整理与实现

参考文献:https://mp.weixin.qq.com/s/Km5KuXPETvG0wCGHrvj9Vg

场景一:git本地版本库的基本用法

初始化一个本地版本库

方法一:

使用ctrl+O快捷键打开一个文件夹(相当于打开一个workspace)
注:某些情况下使用ctrl+O是打开一个文件,而不是打开一个文件夹,这是因为快捷键的设置有问题。

如上图,已经打开了一个workspace(demo1)
接下来为了初始化存储库,打开源代码管理,点击“初始化存储库”或者是在终端使用git init命令(为了熟练掌握git常用命令,以下的所有操作都使用git命令来代替相应的用户界面操作)。
首先使用ctrl+`打开默认终端,并输入git init

至此,实现对git版本库的初始化。

方法二:

在gitee或者是github网站上创建版本库,再通过git clone命令,把版本库克隆到本地完成本地版本库的初始化。

查看当前workspace的状态
git status

暂存更改的文件
将当前工作区中发生的更改加入到暂存区中(点击+号/git add Files),也可以取消暂存(点击-符号/git reset HEAD FILES/git reset HEAD)
例如,我在此项目中新增了文件hello.cpp之后,

(更改的文件由【更改】列表移动到了【暂存的更改】列表里)
取消将文件添加到暂存区(Index),即从暂存区(Index)中删除

(更改的文件由【暂存的更改】列表移动到了【更改】列表里)

把暂存区里的文件提交到仓库
git commit -m "wrote a commit log infro"
如上命令可以把暂存区里的文件提交到本地仓库。
git log
如上命令可以查看提交日志,可以看到当前 HEAD 之前的所有提交记录。
git reset —hard HEAD^
git reset —hard HEAD^^
git reset —hard HEAD~100
git reset —hard 128个字符的commit-id
git reset —hard 简写为commit-id的头几个字符
如上命令可以让HEAD回退到任意一个版本,比如HEAD表示HEAD的前一个版本、HEAD^表示HEAD的前两个版本、HEAD~100表示HEAD的前100个版本,也可以用版本号字符串来指定任意一个版本。

以下是个人演示这几条指令的实际使用:

回退到上一次的版本,也就是没有修改hello.c(初始为空白文件)的时候,

Hello.c重新变成空白状态

通过git reset —hard 回退之后,HEAD指向的不是最新的版本,而git log只能查看HEAD及其之前(时间更早)的提交记录,这是可以使用git reflog查到HEAD指向的版本之后(时间更晚)的提交记录,并且可以再次使用git reset回到未来。

总结:

git init # 初始化一个本地版本库
git status # 查看当前工作区(workspace)的状态
git add [FILES] # 把文件添加到暂存区(Index)
git commit -m "wrote a commit log infro” # 把暂存区里的文件提交到仓库git log # 查看当前HEAD之前的提交记录,便于回到过去
git reset —hard HEAD^^/HEAD~100/commit-id/commit-id的头几个字符 # 回退
git reflog # 可以查看当前HEAD之后的提交记录,便于回到未来
git reset —hard commit-id/commit-id的头几个字符 # 回退

场景二:git远程版本库的基本用法

直接输入git remote之后可以看到默认的远程存储库名称是origin。
git fetch、git push加上git clone是三个对远程存储库的基本操作,而git pull(拉取)是实际上是 git fetch + git merge(合并)的组合。

  • git fetch:下载一个远程存储库数据对象等信息到本地存储库。
  • git push:将本地存储库的相关数据对象更新到远程存储库。
  • git merge:合并两个或多个开发历史记录。
  • git pull:拉取远程仓库里的提交项到本地仓库并合并到当前分支/本地与服务器端同步(git fetch + git merge)。

在github.com上远程创建一个新的b1分支,再上传1.txt文件。
git pull的过程可以理解为:
git fetch origin master //从远程主机的master分支拉取最新内容
git merge FETCH_HEAD //将拉取下来的最新内容合并到当前分支中
即将远程主机的某个分支的更新取回,并与本地指定的分支合并,完整格式可表示为:
git pull <远程主机名> <远程分支名>:<本地分支名>

本地仓库发生如下变化:

有两种修改代码的方法:一种是在本地提交代码到仓库,一种是通过Web界面更新远程仓库,不管是哪种修改,对代码进行修改前都首先进行代码同步操作,防止产生分叉和冲突,这就是使得场景二中所述的工作都是串行的并且及时将本地与远程同步。

场景三:团队项目中的分叉合并

目的:能够独立维护不同的开发者或者是不同的功能模块的代码(让一段连续的工作在commit日志的时间线上呈现为一段独立的分支线段,只在关键点处进行分支合并)。

团队项目的开发者应该采用的工作流程如下:
1.克隆或同步最新的代码到本地存储库。
2.为自己的工作创建一个分支,该分支应该只负责单一功能模块或代码模块的版本控制。
3.在该分支上完成某单一功能模块或代码模块的开发工作
4.最后,将该分支合并到主分支。

同步最新的代码到本地存储库:git pull origin master
创建一个名为mybranch的分支并签出到工作区:

这时使用git branch查看分支列表,如下所示mybranch前面有一个*代表当前工作区处于mybranch分支。
使用git checkout master命令将当前工作区切换到master分支:

合并mybranch分支到当前的master分支(快进式合并:这两个分支会合并到一条时间线中)
git merge mybranch

用--no-ff参数关闭“快进式合并”:
git merge --no-ff mybranch

在自己创建的mybranch分支上,完成一些代码的开发工作(多次执行add和commit命令)
master分支的更改:

mybranch分支的更改:

最后,先切换为master分支,将远程origin/master同步最新到本地存储库,再合并mybranch到master分支,推送到远程origin/master之后

查看github上的网络图,可以发现:

正常合并情况如上图所示,会在master分支上生成一个新节点。

场景四:Git Rebase

一般我们在软件开发的流程中,有一个朴素的版本管理哲学: 开发者要把自己的代码修改按照功能拆分成一个个相对独立的提交,一个提交对应一个功能点,而且要在对应的commit log message里面描述清楚。因此在merge和push之前检查修改一下commit记录时常需要。
场景四实际上就是在场景三的工作流程中增加一步Git Rebase,在mybranch分支上完成自己的工作之后,为了让log记录将来更容易回顾参考,让git rebase重新整理一下提交记录。(注意:不要通过rebase对任何已经提交到远程仓库中的commit进行修改)
git rebase命令格式大概如下:
git rebase -i [startpoint] [endpoint]
[startpoint] [endpoint]指定了一个编辑区间,如果不指定[endpoint],则该区间的终点默认是当前分支的HEAD。指定[startpoint],即为指定从某一个commit节点开始,可以使用HEAD^^,HEAD~100等等。
输入git rebase -i HEAD^^^,打开命令行文本编辑器如下:

删除掉第二行pick 069cb2b revise plus.c,然后:wq保存退出

出现冲突

解决冲突之后执行如下命令完成git rebase

使用git log查看日志可以发现:

revise plus.c的提交记录已经消失

场景五:Fork+Pull request

为了解决开源社区松散团队的协作问题,Github提供了Fork+Pull request的协作开发工作流程。

流程如下:
1.先 fork(分叉) 别人的仓库,相当于拷贝一份;
2.做一些 bug fix或其他的代码贡献;
3.发起 Pull request 给原仓库;
4.原仓库的所有者 review Pull request,如果没有问题的话,就会 merge Pull request 到原仓库中

第一步,在某个项目页面的右上角点击Fork

直接进入新建的版本库,如下图。

第二步,在Fork的版本库中独立工作,并将代码贡献同步到远程的Fork的版本库中。

第三步,创建Pull request。点击Pull request按钮,进入Comparing changes页面,如下图

在Comparing changes页面可以看到Fork的版本库与原仓库之间所有变更信息,页面上有绿色的Create pull request按钮,点击Create pull request按钮即跳转到原仓库,如下图,即可审核变更信息提交Pull request。

第四步,处理Pull request。即原仓库的所有者review Pull request,没有问题的话,就会merge Pull request到原仓库中。

posted @ 2020-10-10 21:48  zxw600  阅读(118)  评论(0编辑  收藏  举报