工作中经常用到Git做版本管理,现在对经常使用的一些用法做一个总结,我来为大家讲解一下关于git常见场景操作?跟着小编一起来看一看吧!

git常见场景操作(关于git日常用法读懂这一篇)

git常见场景操作

工作中经常用到Git做版本管理,现在对经常使用的一些用法做一个总结。

Git 是一个开源的分布式版本控制系统。与svn最大的区别在于,svn是集中式的。集中式版本控制系统的版本库是放在中央服务器的,工作时必须依赖于中央服务器,如果没有网络或者中央服务器挂了,基本所有人都没有工作了。

而分布式版本控制是指每个人电脑里都有完整的版本库,某一个的电脑坏掉了不要紧,随便从其他人那里复制一个就可以了。在本地即使没有网络的情况下,也能完成代码的版本管理。不过为了方便多人协作,会在远程创建一个版本仓库对代码进行托管,如大家常听说的github,gitlab等,供大家同步和共享,这只是形式意义上的“中央服务器”,没有他大家也照样各自干活。

git安装

以windows系统为例,安装过程简单,直接掠过。安装完成后,在开始菜单里找到“Git”->“Git Bash”,弹出一个类似命令行的窗口,说明安装成功。

安装完成后,还需要最后一步设置,在命令行输入:

$ git config --global user.name “Your Name”

$ git config --global user.email “email@example.com”

这两条配置很重要,每次 Git 提交时都会引用这两条信息,说明是谁提交了更新,所以会随更新内容一起被永久纳入历史记录。加了—global选项,那么更改的配置文件就是位于你用户主目录下的那个,以后你所有的项目都会默认使用这里配置的用户信息。

创建版本库

假装是一个标题

假装是一个没有灵魂的副标题

首先建一个空目录,用于存放工程代码。当然,也可以是已经存在的存放工程代码的目录。假设为E:\workspace_test。我想用git来帮我做代码版本管理。做法很简单,打开git bash,cd到这个目录下,输入git init命令,就会在本地建一个空的代码仓库(empty git repository),之后这个目录下所有代码和配置文件的状态变更(包括增,删,改)都能被git跟踪记录。

几个概念:

工作区:

工作区就是原来存放工程代码的目录。工作区所有代码和配置文件的所有状态变化(包括增,删,改)都能被git跟踪。

版本库:

查看workspace目录,发现除了原来的内容,还多了一个名字为.git的目录,这个目录就是版本库,也就是对应上图右侧部分。(版本库中包含一个名字为index或者stage的暂存区;以及git帮我们自动创建的一个名字为master的分支;还有一个指向当前分支也就是master分支的指针HEAD)

暂存区:

进入.git目录,可以看到有一些子目录以及文件,其中index就是暂存区,有时也会叫stage。暂存区是版本库的一部分,用来暂时存放工作区的修改。

HEAD:

.git目录下还有一个名字为HEAD的文件,HEAD代表的是指向当前分支的指针,当我们切换分支时,这个指针就会修改它的指向。

项目初期,只有一个开发人员

场景1:目前只能逐个版本迭代。有一个master分支,建一个dev分支开始开发,开发完成后合并到master。

过程如下:

git branch dev //创建一个名称为dev的分支

git checkout dev //切换到dev分支,即将head指向刚创建的dev分支

开始开发。。。。

git add filename //将工作区发生变更的名称为filename的文件提交到暂存区

Git commit –m ‘新功能开发’ //将暂存区所有文件提交到当前分支dev

新功能开发完成。。。

Git checkout master //切换到master分支

Git merge dev //将dev分支合并到master

场景2:dev分支开发新功能的过程中,有紧急线上bug需要修复,需要等bug修复完后再回来开发,开发完成后合并到master(此时master跟最开始拉取的版本已经不同,因为中途合并了bug修复版本过来)。

过程如下:

git branch //当前在master

git branch dev

git checkout dev

git add filename

git commit –m ‘新功能开发到一半’

开发到一半,需要修复bug

git checkout master //切换回master分支

git brach bugfix //新创建一个bugfix分支

git checkout bugfix

开始修复bug

Git add ….

Git commit –m ‘bug修复’

Git checkout master

Git merge bugfix

Git checkout dev

继续开发

Git add …

Git commit –m ‘新功能开发完毕’

Git checkout master

Git merge dev //可能会产生冲突

因为在将bugfix版本合并到master后,再将新版本开发的版本合并到master,可能修改过同一个文件,这样就会发生冲突。方式是找到冲突文件,手动修改并提交。

项目开发了一段时间,老板要求快速出一个demo,时间紧急,仍然是一个人开发,为了赶进度,经常需要晚上下班后在家加班

目前仅仅有本地代码仓库,要想多地开发,还需要建一个远端代码托管仓库,方便将代码以及版本记录在远程也保存一份。PS: 类似的产品还有许多,如:GitHub、GitLab、Bitbucket、码云等。

为了满足多地开发的需求,需要以下步骤:

STEP1:注册gitlab/github,在上面创建一个空的仓库。

注册GitHub/gitlab;

创建仓库,创建完仓库后会有一个URL代指该仓库。Git可以使用该URL进行向远程推送版本信息或获取版本信息;

由于git和gitlab交互操作会很频繁,为了防止每次操作重复输入用户名和密码,这里需要先进行用户授权。这里介绍使用密钥对的方法,首先创建ssh key:(注意:将email地址换成自己的,输入命令后一路回车即可);

$ ssh-keygen -t rsa -C “youremail@example.com”

这时会在主目录找到.ssh目录,里面有id_rsa和id_rsa.pub2个文件,这两个分别就是ssh key的密钥对,id_rsa是私钥,不能泄漏给别人,id_rsa.pub是公钥,可以放心地告诉别人;

登录gitlab,打开account seetings->ssh keys->add ssh key。可以看到有title和key两个字段需要填写,title内容任意,在Key文本框里粘贴id_rsa.pub文件的内容点击保存即可。日后操作无需用户名和密码;

STEP2 :将在公司写好的代码上传到gitlab托管,也就是将本地仓库与gitlab上的远端仓库做一个关联,并将本地仓库管理的代码推送到gitlab仓库。

Git remote add origin https://*****.git //为地址取一个别名origin,这个是约定俗成的叫法。origin就代表了gitlab上的这个仓库,以后推送拉取代码时可以不用输入url,使用origin别名即可。

git push origin master # 将本地master分支内容以及版本信息推送到Gitlab

Username for ‘https://github.com’: # 输入GitHub用户名

Password for ‘https://wupeiqi@github.com’: # 输入GitHub密码

Git push origin dev #将本地dev分支内容及版本信息推送到gitlab

STEP3: 在家加班时,从远程仓库clone代码到家里电脑

Git clone https://***.git

Git branch dev origin/dev //创建dev分支且和远程dev分支同步

Git checkout dev

开始开发

Git add ….

Git commit –m ‘新功能开发’

Git push origin dev //提交dev分支的内容到远程仓库的dev分支

STEP4:上班后,需要在昨天晚上家里开发的版本基础上继续开发

Git checkout dev

Git pull origin dev //从github获取dev分支最新内容,并合并到本地

开始开发

Git add …

Git commit –m ‘新功能提交’

需要注意到是:执行pull时,相对于两步操作,先fetch,后merge。中间可能会出现冲突。原因是由于本地代码和获取的最新代码有重合部分,那么就需要自己手动解决冲突然后再继续开发。

老板审核demo后,认为这个项目非常重要,需要作为重点项目来推。因此,需要招人,多人协作开发

多人协作开发过程最容易出现的就是冲突。比如其他人已经向origin/dev分支提交了修改,而你修改的文件跟他有些重复,这时,你再向origin/dev push就会提示冲突。

可以尝试以这样的步骤操作:首先,可以试图用git push origin <branch-name>推送自己的修改;如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并;如果合并有冲突,则手动处理冲突,并在本地提交;没有冲突或者解决掉冲突后,再用git push origin <branch-name>推送就能成功!

一些常用命令

end

更多学习资料戳!!!

Redirecting...

,