Git实践——git远程仓库操作

Git实践------git的安装部署与操作https://blog.csdn.net/xiaochenXIHUA/article/details/160568046

一、git远程仓库的创建与推送

1.1、使用git远程仓库的准备

Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。最早，肯定只有一台机器有一个原始版本库，此后，别的机器可以"克隆"这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。可以自己搭建一台运行Git的服务器，每天24小时开机，其他每个人都从这个"服务器"仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。

要快速使用git，可以通过一个叫GitHub的神奇网站，从名字就可以看出，这个网站就是提供Git仓库托管服务的，所以，只要注册一个GitHub账号，就可以免费获得Git远程仓库。

由于本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要设置公钥认证机制（如：GitHub允许添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了【在github上注册账号后，点击右上角的图像图标选择【Settings-->SSH and GPG keys-->NEW SSH key】界面即可添加，如下图所示】）。

实现Linux的密钥对生成------ssh免密登录实操保姆级教程https://blog.csdn.net/xiaochenxihua/article/details/152375722

bash 复制代码

#1-本地生成ssh密钥对语法【ssh-keygen -t ed25519 -C "邮箱地址"】
#注意：-C "邮箱地址"内容是可选的，可以不用（如下命令二选一即可）
ssh-keygen -t ed25519
ssh-keygen -t ed25519 -C "coffeemilk@ck.com"

#2-然后将生成的密钥对中以【.pub】结尾的公钥内容复制一份到github中的"SSH and GPG keys"-->"NEW SSH key"-->"key"下的输入框中

最后友情提示：在GitHub上免费托管的Git仓库，任何人都可以看到（但只有你自己才能改）。因此，不要把敏感信息或项目放进去。若你不想让别人看到Git库，有两个办法：

《1》一个是交点保护费，让GitHub把公开的仓库变成私有的，这样别人就看不见了（不可读更不可写）。

《2》另一个办法是自己动手，搭一个Git服务器，因为是你自己的Git服务器，所以别人也是看不见的。

1.2、创建远程仓库

以使用github远程仓库为例说明：点击github右上角的加号(+)-->New repository-->在弹窗界面根据提示输入项目的名称"Repository name*"、描述"Description"、仓库类型"Choose visibility"、是否启用项目说明文档"Add README"、项目证书内容"Add license"，最后点击创建仓库"Create repository"如下图所示：

1.3、初次将本地仓库推送到远程仓库

bash 复制代码

#初次将本地仓库推送到远程仓库

#1-获取到远程仓库的git地址（如：git@github.com:kafeiweimei/gitdemo.git）

#2-进入本地仓库，并将本地仓库设置远程仓库的git地址【git remote add origin 远程仓库的git地址】
#注意：执行如下命令后，则远程仓库库的名字就是【origin】（这是Git默认的叫法，也可改成别的，但是origin这个名字一看就知道是远程库）
cd /data/gitlearn/gitdemo
git remote add origin git@github.com:kafeiweimei/gitdemo.git

#3-把本地库的所有内容推送到远程库上（若报错，则参考如下的解决方案）
git push -u origin master

#4-在github的远程仓库上切换到【Master】分支查看

注意：在将本地仓库的所有内容推送到远程库上时，若报错"

The authenticity of host 'github.com (20.205.243.166)' can't be established.
ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'github.com' (ED25519) to the list of known hosts.
git@github.com: Permission denied (publickey).
致命错误：无法读取远程仓库。

"总结起来就是"你已经成功生成了 SSH 密钥，但因为你把密钥存在了**非默认路径(~/.ssh/)**而是自定义的路径（如： /data/sshkey/github/id_ed25519），Git/SSH 不会自动找到它，所以还是会报权限错误"，解决方法如下：

bash 复制代码

#解决执行【git push -u origin master】命令将本地仓库内容推送到远程仓库报"权限错误"

#1-指定SSH生成的私钥路径来测试与github连接命令测试（结果显示"Hi 你的用户名! You've successfully authenticated, but GitHub does not provide shell access."则表示【公钥是对的，只是SSH没加载这个密钥】）
ssh -i /data/sshkey/github/id_ed25519 -T git@github.com

#2-配置SSH可识别密钥
vi ~/.ssh/config
#【~/.ssh/config】文件的完整内容
Host github.com
    HostName github.com
    User git
    IdentityFile /data/sshkey/github/id_ed25519
    
#3-再次测试与github的连接（结果显示"Hi 你的用户名! You've successfully authenticated, but GitHub does not provide shell access."则表示配置正确，可直接使用了）
ssh -T git@github.com

1.4、非首次将本地仓库内容推送到远程仓库

把本地库的内容推送到远程，用【git push】命令，实际上是首次把当前分支master推送到远程，由于远程库是空的，因此第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。

从现在起，只要本地作了提交，就可以通过命令【git push origin master】本地master分支的最新修改推送至GitHub，现在，你就拥有了真正的分布式版本库！

bash 复制代码

#非首次将本地仓库内容推送到远程仓库

#1-在本地仓库新增文件
cd /data/gitlearn/gitdemo
cp /etc/yum.repos.d/almalinux-baseos.repo .

#2-将新增的文件先保存到暂存区，紧接着就提交到仓库中
git add almalinux-baseos.repo
git commit -m "add file almalinux-baseos.repo"

#3-最后推送本地仓库内容到远程仓库
git push origin master

#4-打开github的远程仓库地址进入master分支查看情况

1.5、从远程仓库克隆

前面讲了先有本地库，后有远程库的时候，如何关联远程库。现在，假设从零开发，那么最好的方式是先创建远程库，然后，从远程库克隆。

Git支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议（如：https://github.com/kafeiweimei/gitdemo.git）但通过ssh支持的原生git协议速度最快。使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，而在某些只开放http端口的公司内部可能无法使用ssh协议，此时只能用https。

bash 复制代码

#从远程仓库克隆
#1-获取远程仓库的git地址（如：git@github.com:kafeiweimei/gitdemo.git）

#2-进入存储该仓库的目录下克隆
mkdir -p /data/gitlearn/clonetest
cd /data/gitlearn/clonetest
git clone git@github.com:kafeiweimei/gitdemo.git


#3-项目操作测试（如：新增目录并在该目录下创建多个文件，然后将该目录下的所有文件都添加到仓库暂存区，最后统一提交到仓库中）
#3.1-创建test目录
mkdir test
cd test

#3.2-在新建的test目录下新增文件devtest
cat >> devtest <<EOF
this is a develop test message
you can write program file
EOF
#3.2-复制文件到当前目录
cp /etc/hosts .
cp /etc/host.conf .

#3.3-将当前目录下的所有文件都添加到本地仓库暂存区中；最后统一将暂存区中的都都提交到仓库中
git add .
git commit -m "add file hosts host.conf devtest"

#3.4-推送本地仓库所有内容到远程仓库
git push origin main

#3.5-打开远程仓库地址的main分支查看内容是否同步上

二、git分支管理

2.1、分支的概念

假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你可以创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

2.2、创建与合并分支解析

在版本回退里，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。当我们创建新的分支（如：dev分支时，Git就新建了一个叫做dev的指针，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上）：

可以看到，Git创建一个分支很快，因为除了增加一个dev指针，修改HEAD的指向外，工作区的文件都没有任何变化！不过，从现在开始，对工作区的修改和提交就是针对dev分支了（如：新提交一次后，dev指针往前移动一步，而master指针不变）：

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

2.3、创建与合并分支示例

bash 复制代码

#创建与合并分支示例
#1-进入当前git仓库中，并创建分支且进入新建分支(如：dev)
#注意：【git checkout -b dev】命令表示"创建并切换"，相当于【git branch dev】+【git checkout dev】
#注意：在Git2.23+后可使用【git switch -c dev】命令表示"创建并切换dev分支"，相当于【git create dev】+【git switch dev】
cd /data/gitlearn/gitdemo/
git checkout -b dev

#2-查看当前使用的分支
git branch

#3-对当前的dev分支内容修改，然后将修改内容添加到暂存区，并提交到仓库中
#3.1-修改dev分支中的readme.txt文件
cat >>readme.txt <<EOF
new add dev branch
EOF
#3.2-将修改文件添加到暂存区并提交到仓库中
git add readme.txt
git commit -m "append 'new add dev branch'"

#4-此时切换到master分支（查看readme.txt文件内容还是未修改前的内容）
git branch
git checkout master
cat readme.txt

#5-此时在master分支下进行合并dev分支后（所有的文件修改就有了）
git branch
git merge dev
git branch
cat readme.txt

#6-分支合并完后，若觉得dev分支没有必要了，就可以将它删除
git branch -d dev
git branch

2.4、冲突解决

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。用【git log --graph】命令可以看到分支合并图。

bash 复制代码

#冲突解决
#1-进入仓库中，并创建新分支
cd /data/gitlearn/gitdemo
git switch -c ops_dev

#2-在新分支下修改文件
cat >>readme.txt <<EOF
> create a new branch is quikly and simple.
> EOF

#3-将修改后的文件添加到仓库暂存区后并提交
git add readme.txt
git commit -m"append 'create a new branch is quikly and simple' to readme.txt"


#4-切换到原来的master分支（并查看当前分支）
git checkout master
git branch

#5-在master分支下修改文件
cat >>readme.txt <<EOF
> increase a new branch is simple & quik.
> EOF

#6-将修改后的文件添加到仓库暂存区后并提交
git add readme.txt
git commit -m"append 'increase a new branch is simple & quik.' to readme.txt"

#7-在master分支合并ops_dev分支（此时会合并失败，可以通过查看状态了解是哪些文件有问题;然后再查看具体的问题文件了解内容）
git branch 
git merge ops_dev
git status
cat readme.txt

#8-编辑有冲突的文件（根据实际的情况保留对应的内容：如这里只保留increase a new branch is simple & quik.）后保存

#9-将修改后的文件添加到仓库暂存后并提交
git add readme.txt
git commit -m"conflict fixed"

#10-通过git log命令查看分支的合并情况
git log --graph --pretty=oneline --abbrev-commit

#11-确认无误后可将ops_dev分支删除
#注意：若要丢弃一个没有被合并过的分支，可以通过【git branch -D <name>】命令强行删除
git branch -d ops_dev

在master分支和ops_dev分支各自都分别有新的提交，就变成如下图这样（这种情况下，Git无法执行"快速合并"，只能试图把各自的修改合并起来，但这种合并就可能会有冲突）：

手动编辑有冲突的文件后，再次查看master分支和ops_dev分支的情况，则如下图所示：