1、简介
在使用git中我们可以发现,GIT现在并没有使用严格的网络要求,但是个人所编写的代码要给其他人使用,那么必须要将项目的代码公布到网络上,所以在GIT创建之初,也考虑到了此类的问题,提供了这个网站https://github.com/。 GIT的公共服务器。
但是在网站上在进行网站发布的时候需要 注意一点,他可以发布两类项目。
- 公共项目(免费):你可能需要将你的代码交给其他人进行完善。
- 私有项目(收费):作为公司的项目。现在微软已经让我们免费使用了哈哈哈
2、远程仓库
GITHUB就是一个服务器,他可以保存各个客户端发送来的数据。但是如果要进行保存数据,使用SSH的通讯模式,需要配置如下:
-
启动 GIT BUSH;
在此命令行窗之中可以执行Linux命令
-
在此窗口中声称如下的SSH key 命令
ssh-keygen -t rsa -C "注册邮箱"
命令输入之后,那么会首先询问用户改密钥的保存位置。
默认情况下他会将公钥与私钥保存在用户的/.ssh目录中。
之后会提醒设置一个保存密码,输入的时候不回显。
随后会出现如下的显示界面。
我们现在有了公钥与私钥,我们需要将我们的公钥配置到我们的GITHUB上。
首先找到我们公钥的保存位置 C:/用户/.ssh
-
公钥文件:id_rsa.pub,保存在外部中使用
-
私钥文件:id_rsa,做本机的标识
需要将公钥配置到GITHUB之中,回到github中的设置页面
点击此链接,随后选择“add ssh key”,接着输入名称以及我们的公钥内容。
-
以后本台电脑就可以用ssh的连接方式与github进行代码的交互操作了。
新建远程仓库的步骤 :
画红线的地方实际上给出了仓库的两种访问地址:
- SSH: git@github.com:HappyXiangZi/erp.git
- HTTPS: https://github.com/HappyXiangZi/erp.git
删除仓库的方式:
在仓库的settings处划到最后,点击delete repository。
3.客户端访问
-
建立客户端与服务端的连接地址信息
git remote add origin git@github.com:HappyXiangZi/erp.git
注意: 输入上面的代码之前首先应该将控制台目录切换到git文件夹目录之下
-
连接建立成功之后,需要将本地仓库中的全部代码推送到服务器端。
git push -u origin master
-
如果说本地仓库的代码又进行了修改
- 将本地仓库的修改提交到master分支上
git commit -a -m "add a file"或者执行以下两行代码
git add.
git commit -m "add a file"
2.此时提交的代码是在本地的master分支上,还需要将本地的master分支提交到服务器之上。
git push -u origin master
发现刚才在本地中创建的文件已经上传到网上的服务器当中去了。
4. 克隆远程仓库
在之前的操作形式是远程先创建一个空的仓库,而后将本地上传到服务器上。
在创建仓库的时候直接进行初始化仓库,表示远程服务器端是一个直接可用的仓库。随后将远程服务器端的代码克隆下来。
-
创建文件夹
-
进入文件夹
-
克隆
git clone https://github.com/HappyXiangZi/cnm.git
- 之后的操作跟上边完全一样。
5.创建和合并分支
在GIT中会存在大量的分支操作,最为重要的分支未master分支,所有最终要使用的代码都定义在master分支上,所以不能在master上编写代码,所有的开发应该都在子分支上,每一开发者都可以开发属于自己的分支操作,不会与其他的开发者产生冲突。
-
查看当前可用的分支
git branch
当前的目录就只有一个master分支,*号表示当前所处的分支,每一个分支都是彼此各自独立的分支。
-
创建一个新的分支
git branch dev
创建一个Dev 分支
-
进行代码开发必须在子分支上进行,所以现在需要切换到Dev分支上。
git checkout dev
假设现在master分支不操作,现在在dev分支上写上操作代码,新增dev.txt文件。此时master分支上不存在dev.txt 文件,要想让其真正使用,需要将将其提交到dev分支上
-
增加文件到暂存区而后提交版本库
现在再Dev分支上就在master上具备更多的内容,为了更加清楚地
-
为了更加清楚的观察出分支之间的关系,下面将分支在master与Dev分支进行切换。
执行以下代码:
git checkout master
此时可以观察到刚刚新增的dev.txt文件不见了,因为master分支上是没有dev.txt文件的。
6.切换回master分支,然后进行分支合并。
git checkout master
git merge dev
这种合并过程是最快的,但是未必是最好的,因为现在有一个前提,master分支并没有进行任何的修改,
实际上任何的项目开发都不可能是一蹴而就的,包括分支也是一样的。所以在进行远程仓库提交的时候必须将所有的分支都提交到我们的服务器上。
git push -u origin master
git push iu origin dev
6.冲突解决
可能存在着这样的情况:两个分支同时修改了同一个文件,两个分支在进行合并的时候就一定会出现冲突。
-
创建并切换到dev分支上。
git checkout -b dev 等价于以下: git branch dev git checkout dev
-
在dev上创建一个新的文件action.txt 修改sss.txt
-
在dev分支上,把工作区的内容提交到版本库中。
-
切换到master分支上,随后也对sss.txt 进行修改,将其提交
现在再master分支和dev分支上都对同一个文件进行了修改。
-
在master上合并dev分支
出现分支冲突,不能够进行分支的合并。
此时查看我们的sss.txt文件:
下面手工解决冲突,删除不必要的代码:
现在文件可以进行正常提交了。
-
最后将代码提交到我们的服务器上
git push -u origin master
7.分支合并模式
我们前面所使用的分支合并的模式的“fast-forward”模式,我们可以通过图形化命令查看:
git log --graph --pretty=oneline
或者我们使用GUI 工具
默认情况下,fast-forward并不会产生新的提交点日志,但是这样的操作严格来讲并不合理,但是为了保证记录的完整性,在合并的时候就需要加上 “-no-ff”的参数
git merge --no-ff -m "use no-ff Merge" dev
8. bug分支
为了解决临时的开发矛盾,GIT中提供一个暂挂功能,可以将现在的工作区暂时挂起,等处理完矛盾之后恢复原来的工作区,所以这样的操作称为bug的修复操作过程。例如:master出现了bug,但是此时程序员正在dev分支上进行开发。
-
假设现在再dev分支上进行开发
-
而后在这个分支上修改了一些代码,但是还没有完成,所以此时并不能提交给版本库,也不能提交到暂存区。为了处理master分支上的bug,可以将当前的工作状态保存起来。
-
当前的工作状态保存起来
git stash
-
切换到master分支上进行代码的修复;
git checkout master
-
在master 分支上创建bug分支
git checkout -b bug
-
在bug分支上进行错误的修正。
-
将bug分支修改的内容进行提交,与master分支进行合并
git add . git commit -m "solve pro bug" git checkout master git merge --no-ff -m "bug repaired" bug git branch -D bug
直到现在所有bug的修复已经完成了,但是此时自己dev分支的开发工作还没有结束,所以需要切换到自己的工作区中。
-
查看所有暂时挂起的工作区
git stash list
-
已经知道了暂时挂起的工作区,就进行恢复。先切换回自己的分支
-
分布完成:
git stash apply #恢复暂存区 git stash drop #清除最后一个暂存区
-
一步完成:
git stash pop
-
9. feature(扩展分支)
假设有一个项目已经运转正常了,突然被要求说要开发一个投票功能,正当程序员已经开发到一半的时候,领导开会讨论说要取消这个功能,所以这个修改等同于做了无用功,不能够提交,同时,他所再发的功能一定是在一个新的分支上,我们叫做feature分支。
-
创建并切换到feature分支上。进行项目的更新开发
git checkout -b feature
- 开始在这个分支上进行一系列的代码编写。
- 编写完毕之后,提交到feature分支上,功能被取消了,所以这个分支不能被合并,并且应该立刻取消掉。
git checkout master git branch -D feature # 这里使用D 表示强制性删除,否则会出现错误 d表示一般删除
10. 补丁
-
创建并切换到dev1分支上;
-
修改里面的文件信息。
-
查看两个文件的不同。
git diff sss.txt
-
现在只是增加了一行新的内容,将修改后的结果保存在dev1 分支上
-
此时dev分支上的内容是最新的,而master分支上的内容不是最新的,按照传统上来讲,应该将master分支与Dev1分支进行合并,但是这样的操作过程太过复杂了,我们可以将master分支与Dev1上的不同设置为一个补丁文件;
#当前是在Dev1 分支上 git diff master > patch
随后在master分支上应用补丁信息。
git checkout master git apply patch #应用补丁
但是这种做法严格来讲是有一定局限的,因为这种方式通常是建立在开发者沟通充分的情况之下,所以最好使用的是一种格式化补丁的方式(format-patch)。
-
创建并切换到pat分支。
git checkout -b pat
-
在pat分支上实现代码的修改
-
将所做的修改进行保存。
git add . git commit -m "change sss.txt on pat"
-
但是这个时候所做的修改必须通知远程的开发者本人
git format-patch -M master
随后在当前的工作目录会出现一个修改文件。在这个文件里面会直接取出全局配置里面的联系邮箱和用户名,并且使用一种固定的格式将补丁文件进行保存。
-
随后这个补丁应该通过邮箱发送给指定的开发者,而当开发者接收到这个邮件并且认可,要将其发布到最终的项目版本中。
git checkout master git am 文件路径
-
随后只要在master分支上进行文件的提交即可。
git add . git commit -m "Apply patch"
以后如果要求严格的时候,千万不要区完全上传这个文件,只要传递部分修改即可。
11.多人协作开发
如果想知道有哪些远程仓库,可以使用如下的命令:
git remote
要想取得更加详细的的信息:
git remote -v
在这个信息里面给处理明确的抓取更新的远程仓库地址,以及推送更新的远程仓库地址
随后需要打开一个新的窗口以及一个新的路径,然后在这个路径下将erp的内容克隆下来。
git clone git@github.com:HappyXiangZi/erp.git
但是通过这种方法克隆下来的项目只有master分支而没有dev分支。
抓取github上的dev分支,同时为了区分,在本地将其变为 zyx分支
git checkout -b zyx origin/dev
此时严格来讲,只是将本地分支zyx与远程分支dev分支关联上了但是还没有抓取数据下来。(因为名称不一致,否则不会存在这种问题)
抓取数据有两种方式:(pull 、fetch)
git branch --set-upstream-to=origin/dev zyx git pull
执行以上两行代码就可以完成抓取,如果名称一样则不需要此操作
删除远程仓库的分支:
git push orgin --delete :分支名称
-
12.git标签
一旦使用了这些标签,在进行版本穿越的时候就可以使用标签的名称即可。一般情况下可以用以下的命令将当前的提交点ID设为一个标签。
范例: 将当前的提交点设置为 v1.0版本标签。
git tag v1.0
随后只需要输入
git tag
查看当前的所有标签
我们可以找到左右的提交点编号,而后设置相应的标签。
范例:找到提交点。(简写)
git log --prety=online --abbrev-commit
范例:设置三个标签:v0.1
git tag v0.1 提交点ID
范例:查看标签
git show v0.8
范例:为每一标签设置标签的文字
git tag v0.1 -m "message"
范例:删除标签
git tag -d v0.1
范例:将v1.0标签提交到服务器上
git push origin v1.0
范例:批量提交标签
git push origin --tags
范例:远程标签的删除
git tag -d v0.1 #删除本地
git push origin :refs/tags/v0.1 #删除远程