Github仓库的创建

我们想要在全球最大的同性交流网站上提交你自己本地的版本仓库,那么首先就需要注册一个Gtihub账号,具体的操作无非就是邮箱注册这些,为了方便演示,我初始化了我本地的版本仓库,并创建了一个Firstfile

This is the first line and commit
SEELE@DESKTOP-RHPQ0IE MINGW64 /F/Gitfile (master)
$ git status
On branch master
nothing to commit, working tree clean

这时候我们进入github的页面中Create a new repository创建新的仓库这个界面

创建仓库.png

  • 因为我选择的是免费的github,所以只能使用Public仓库
  • README我自己写,所以不需要添加,这个仓库我只用作测试与演示,所以不需要添加语言备注.gitignorelicense

这样我的一个新的仓库就创建好了

仓库创建好了.png

因为我并没有配置README这个Markdown,所以我要在自己的本地版本仓库配置一个README文档,并提交到我的本地缓存区

SEELE@DESKTOP-RHPQ0IE MINGW64 /F/Gitfile (master)
$ vim README.md
## This repository is used for my Git and Github learning

# author

* YQHP-YuKi
SEELE@DESKTOP-RHPQ0IE MINGW64 /F/Gitfile (master)
$ git status
On branch master
nothing to commit, working tree clean

这时候我们就需要将此时的本地版本仓库提交到Github的仓库,我们就可以用到此条命令:

git remote add origin

意思就将你本地的仓库关联到远程仓库的地址,后面加上你远程仓库的HTTPS

$ git remote add origin https://github.com/YQHP-YuKi/Gitleaning.git

然后再加上此命令:

git push -u origin master

这条命令意思就是将本机上的master分支推送到远程版本仓库并与之相关联

$ git push -u origin master
Enumerating objects: 6, done.
Counting objects: 100% (6/6), done.
Delta compression using up to 12 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), 583 bytes | 583.00 KiB/s, done.
Total 6 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/YQHP-YuKi/Gitleaning.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

输入你的Github账号密码即可

这时候我再刷新我的Github的仓库网页,就看见将本地master传上去了

传上去1.png

传上去2.png

Git远程操作

我们在本地Git执行一些命令,可以查看到本地Git仓库与外界服务器版本库有哪些关联

  • git remote show
SEELE@DESKTOP-RHPQ0IE MINGW64 /F/Gitfile (master)
$ git remote show
origin

这条命令就可以看到我本地版本库就只与Github上面的版本库做了相关联,如果我与Gitlab或者其他服务器做了关联,也会罗列出来

  • git remote show + 版本库名字:了解详细信息
SEELE@DESKTOP-RHPQ0IE MINGW64 /F/Gitfile (master)
$ git remote show origin
* remote origin
  Fetch URL: https://github.com/YQHP-YuKi/Gitleaning.git
  Push  URL: https://github.com/YQHP-YuKi/Gitleaning.git
  HEAD branch: master
  Remote branch:
    master tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)

注:罗列出了我FetchPush拉取推送的网址,并且显示了与本地相关联的分支,且当前状态下相互合并的状态

基于Git分支的开发模型
  • develop分支(频繁变化の一个分支)
  • test分支(供测试和产品等人员使用的一个分支,变化不是特别频繁)
  • master分支(生产发布分支,变化非常不频繁の一个分支)
  • bugfix(hotfix)分支(生产系统中出现了紧急的Bug,用于紧急修复的分支)
使用SSH连接远程Github仓库

使用HTTPS连接并不是我们连接Github仓库的主流方式,因为当使用HTTPS/HTTP协议建立本地仓库与远程厂库联系时,不需要进行任何配置,但是每次进行推送都需要输入账号密码,而使用SSH协议,只需要进行一次配置,就可以实现免密推送,我们主流连接主要是使用SSH进行连接,所以现在我重新连接Github仓库

因为我是已经连接到了我的Github的仓库的,所以相当于我已经将远程仓库GithubIP地址添加到了本地信任地址中,如果每有关联,则执行此命令:

git remote add origin +你的SSH链接

接下来,使用以下命令生成本地计算机的公钥和私钥

ssh-keygen

进入ssh

cd ~/.ssh

打印公钥

cat id_rsa.pub

生成秘钥1.png

注:在生成过程中,可以选择公钥和私钥的保存地址,默认是保存在.ssh文件夹下的,还可以设置密码,也可以不设置,直接回车即可生成公钥和私钥

接下来我们要做的就是把生成的公钥部署到远程仓库Github上,如图所示:

公钥1.png

在该界面可以添加多个公钥,如果项目组有多个成员,或者一个人使用多台电脑可以设置多个公钥

公钥2.png

公钥与私钥的地址都在你ssh-keygen下面的文件路径里面,注意:一定要勾选Allow write access选项,否则无法将本地仓库代码推送到远程仓库,并且添加时要输入Github账号密码进行确认

公钥3.png

添加完成后,就可以在原来的界面看到新增的公钥了,这样使用该公钥的本地计算机就具有了读写这个远程仓库的权限了

如果你原来也是用的HTTPS,这时候也配好了公钥,这时候只需要git clone +你原来的HTTPS让两个版本库一样,再去修改.git/config下的url即可:

修改url.png

有3种方法可以查看到你是否已经将本地仓库关联到远程仓库:

git remote //只显示远程仓库地址名
git remote -v //显示远程仓库地址名和对应URL
git remote show origin//显示详细信息

3种方法.png

实际开发中,通常会使用SSH协议进行本地仓库与远程仓库的连接,因为只需要配置一次公钥,就可以免密推送,十分方便:

添加账户SSH

之前在Github上的Gitlearning仓库中添加了一把SSH公钥,但该SSH KEY仅限于本地与test仓库的通信,不能在其他仓库中使用

只能一个使用.png

如果我们想让Github上的所有仓库都使用同一把SSH KEY,就需要配置针对账号的SSH KEY

全局1.png

Seeting中新建全局的SSH KEY

全局2.png

Git协作

SVN方式(典型模型)

协作.png

现有两位工作人员,分别为AB,还有个就是远程仓库C

  1. A首先将本地仓库的代码推送push到远程仓库C中,此时AC两个仓库的文件一致
  2. 接下来BC的代码拉取pull下来,此时A,B,C三者之间的仓库是一致的,然后AB分别在各自的本地进行开发,并向各自的本地仓库进行了数次commit
  3. 这时候A再向C推送修改过后的本地仓库文件,由于先前A,B,C三者一样,现在A做了修改,相当于C中文件A都有,所以不发生冲突,所以可以直接推送,不用先执行git pull
  4. 这时候B也想向远程仓库C推送自己修改的文件,但却出现了失败,这是因为:此时的C中有A做出的修改,不能让B进行覆盖,此时B想要成功推送,只能先将C的文件拉取pull到本地,拉取pull时候有两种情况:

    • 成功(success):说明AB修改的不是同一个文件,采用Fast-forward方式自动合并
    • 失败(fail):说明AB修改了同一个文件,这时候就需要B手动解决冲突并合并
  5. B成功的将C中的文件pull到了本地并合并成功后,就能将B对本地仓库所做的修改推送push到远程仓库C了,此时CB的版本库则也完全一样了,但与A不一样了

注:在整个过程中,可以发现远程仓库C仅仅是起到了代码第三方托管的作用,不同于SVN的远程仓库C,SVN的仓库只有远程C一个,用户AB都没有,假如C出问题了,会导致所有的提交信息都丢失,而git的分布式管理系统则不会出现这种情况

本地远程分支

当我在与Github仓库进行关联后,再执行git status时,我们会发现与以前没关联的时候有了一些细微的变化

有细微变化.png

  • git中其实有三种分支:本地分支,本地远程分支,远程分支
  • 可以这样理解:本地远程分支是远程分支的一个镜像,并且在本地仓库与远程仓库之间起到一个桥梁的作用
  • 在没有办法直接查看远程仓库的时候,可以通过本地远程分支观察远程分支的变化情况,比如本地远程分支origin/main就对应着远程分支main

正如图所示,origin/main为本地远程分支,代表的是远程仓库的main分支,而这个分支是在本地的,也就是说加上远程仓库的main分支,一共有三个master分支

图片表示三个master.png

并且,当本地仓库中的每一个分支都有与之关联的远程分支之后,本地仓库都会创建对应的本地远程分支,他们所处的位置和关系如图所示

三个master对应关系1.png

可以这样理解:本地远程分支origin/master为远程分支master的本地化形式

假设远程仓库和本地仓库文件内容是一样的,都只有两次提交,此时三个分支的状态如下图所示

三个master对应关系2.png

当我尝试从master切换到origin/master时,会出现这种:

切换到origin的master.png

所以对于origin/master你是最好不要手动改变,因为这个分支是由git pushgit pull来进行改变的

模拟多人协作

假如我是一名程序员B,我想把github上面的项目C给下载到本地,进行版本开发,我可以使用这条命令

git clone +SSH 或者 +HTTPS

git clone1.png

  • 我们可以发现名字自动就成了仓库C的名字

我进去看看

SEELE@DESKTOP-RHPQ0IE MINGW64 /F/Gitfile2
$ cd Gitlearning/

SEELE@DESKTOP-RHPQ0IE MINGW64 /F/Gitfile2/Gitlearning (main)
  • 可以发现自动切换到的master分支

为什么会造成这种原因了,那是因为,我切回到程序员A提交的仓库看看

默认就是master.png

我们程序员A最先前就是默认的master分支

其实我们程序员B克隆仓库C不一定必须也叫Gitlearning,我们也可以自己设置,我现在就删除,重新创建一个,在SSH或者HTTPS后面跟你想要的仓库名字即可

自定义仓库名字.png

然后我们配置B程序员的仓库,使与程序员A保持不一致

ProgramerB仓库.png

现在程序员A与程序员B的仓库还有远程C完全一样

正式开始

我们先在A这边更新一个文件,并提交到C

A第一次提交.png

C成功看到A第一次.png

这时候我们B查看一下版本:

B第一次显示落后了.png

我们这时候想让BAC都一样,则需要执行git pull命令

B第一次更新成功.png

  • 可以看到我历史从A047125d更新到了109b726
  • 仓库中多了一个ProgramAfile1.txt
  • 上图中有条横线表示,在pull操作的过程中B中的master分支与远程仓库C中的master分支采用了Fast-forward方式进行了合并,并达到了同步

    • 关于Fast-forward方式之前已经讲解过了,在上述合并过程中origin/master分支直接指向了最新提交,中间没有其他分支,也就不会出现合并冲突,这种合并方式称为快进,如图所示:

Fastfoward快进.png

  • 这是一个理想的情况,很多情况下执行git pull操作时,都会出现合并冲突,需要手动解决冲突,再手动进行合并
git pull同源合并冲突

这时候我们ABC三者的仓库仍然是相同的,我开始分别对AB进行修改

两者修改同一文件不同修改.png

  • 这时候AB修改的是同一个文件,但修改的东西是不一样的,且两个都分别提交到了本地的版本库

这时候我们先让A进行git push,再让B进行git push试试

B出现了第一次报错.png

这时候B出现了报错,显示你push失败是因为你的修改已经被其他仓库员所提前提交了,建议你使用git pull进行修改

我们查看下CB

B失败的仓库.png

A提交到C的仓库.png

我们可以发现AC已经同步了,但是B是不一样的,我们就按照提示所做做git pull试试

自动pull合并失败.png

可以看到提示自动合并失败了,建议你手动修改那个文件并提交你的结果

Last modification:January 30th, 2021 at 06:10 pm