Linux中Gitee的使用

一、Gitee简介：

        Gitee（码云）是中国的一个代码托管和协作开发平台，类似于GitHub或GitLab，主要面向开发者提供代码管理、项目协作及开源生态服务。

适用场景

• 个人开发者：托管私有代码或参与开源项目。

• 中小企业：低成本搭建代码管理平台。

• 教育机构：教学或学术项目管理。

对比GitHub

• 优势：国内访问稳定，中文支持好，符合本地法规。

• 不足：国际影响力较弱，开源生态规模较小。

总之，Gitee是中国开发者常用的Git托管平台，尤其适合需要高效协作和本地化服务的团队。

二、Linux中Gitee的应用

1、创建Git目录

代码如下：

mkdir gitecode(此处目录可自行起名字)

2、创建本地Git

        在所创建的目录下建立本地gitee，代码如下：

git init

3、检测是否建立成功

        .git即为刚刚所建立的本地仓库

4、Git的配置

（1）配置name和email

        建立本地gitee后，我们需要配置name和email ，这里就需要大家填写自己创建Git是的信息了，我这里是随便填的用来演示的。

代码如下：

git config user.name "Git用户名"
git config user.email "Git创建时的邮箱"

（2）查看配置文件

代码如下：

git config -l

（3）删除配置文件

        想必大家有可能会手残配置出错等情况，不过不要慌，我们这里还有删除配置操作代码如下：

git config --unset (user.name)此处为要删除的配置

（4）--globle

        作用在系统的全局下配置的文件在所有的Git文件中都生效。

代码示例：

git config --global user.name 'LWF' 
git config --global user.email '123123@qq.com'

与此同时，我们需要注意这里删除全局的配置文件时也需要加--global,否则删不掉。

代码示例：

git config --global --unset (user.name)此处为要删除的配置

5、认识工作区、暂存区、版本库

        修改（add）：新增、修改、删除（这几个操作都算修改）

        修改的工作内容会写入对象库的一个新增的git对象中。

示例图如下：

6、添加文件

（1）场景1：

        我们可以通过一些指令来连接工作区和版本区。

git add (工作区已“修改”的文件)
//git add . 表示添加当前工作区下全部已修改的文件
git commit -m "这里面填写修改的细节相当于日志，不要乱写"

（2）查看add（修改）内容（日志）

        由上述图片我们可以知道.git的objicts目录会记录修改内容那我们如何查看呢？

当然，这里我们也是可以通过指令来查看的。代码：

git cat-file -p -(该部分为加码部分需要在自己系统查看)
//效果见下面图即可理解

（3）场景二：

        在添加文件时我们可能遇到下面的场景，我们的目的是将file1和file2同时提交到本地仓库中但是我们会发现我们只提交了file1。原因是我们只将file1添加到了暂存区，而git commit 只会提交暂存区的内容。

        要想将file2也提交到本地仓库只需如下操作即可：

7、修改文件

        Git ⽐其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，⽽⾮⽂件。

什么是修改？

        ⽐如你新增了⼀⾏，这就是⼀个修改，删除了⼀⾏，也是⼀个修改，更改了某些字符， 也是⼀个修改，删了⼀些⼜加了⼀些，也是⼀个修改，甚⾄创建⼀个新⽂件，也算⼀个修改。

（1） git status

        该命令⽤于查看在你上次提交之后是否有对⽂件进⾏再次修改。

使用效果可看图中示例：

        初始时我们是nothing to do，新建文件即（修改操作）是我们的状态是需要将文件add到暂存区。

       添加之后我们的状态是需要将其提交到本地仓库：

        提交成功后会发现我们的状态又会回到初始的状态

（2）git diff [file]

        git diff [file] 命令⽤来显⽰暂存区和⼯作区⽂件的差异，显⽰的格式正是Unix通⽤的diff格式。也可以使⽤ git diff HEAD -- [file] 命令来查看版本库和⼯作区⽂件的区别。

图中的-1

8、版本回退

        之前我们也提到过，Git能够管理⽂件的历史版本，这也是版本控制器重要的能⼒。如果有⼀天你发现 之前前的⼯作做的出现了很⼤的问题，需要在某个特定的历史版本重新开始，这个时候，就需要版本 回退的功能了。

        执⾏ git reset 命令⽤于回退版本，可以指定退回某⼀次提交的版本。要解释⼀下“回退”本质是 要将版本库中的内容进⾏回退，⼯作区或暂存区是否回退由命令参数决定：

git reset 命令语法格式为： git reset • [- soft | - mixed | - hard] [ HEAD]

        --mixed 为默认选项，使⽤时可以不⽤带该参数。该参数将暂存区的内容退回为指定提交版本内 容，⼯作区⽂件保持不变。

        -- soft 参数对于⼯作区和暂存区的内容都不变，只是将版本库回退到某个指定版本。

        -- hard 参数将暂存区与⼯作区都退回到指定版本。切记⼯作区有未提交的代码时不要⽤这个命 令，因为⼯作区会回滚，你没有提交的代码就再也找不回了，所以使⽤该参数前⼀定要慎重。

下面我们可以通过一张图片来了解一下上面的概念git 表示回退的内容。

图中的git表示回退，git work 表示未回退。

        这里我们演示一下--hard 指令（hard指令会直接将你原有的代码文件全部回退因此要慎重使用），当然如果这里我们回退错了也可以回退到未回退的状态（前提有未执行回退操作时的id）。

        上述操作，是需要git log 来查看原有的id，运气好的话我们能查到，但总会出现一种情况就是git log 的内容被刷新掉找不到原始的id,这是我们怎么办呢？

        Git 还提供了⼀个 git reflog 命令能补救⼀下，该命令⽤来记录本地的每⼀次命令。

9、撤销修改

情况⼀：对于⼯作区的代码，还没有 add

        对于⼯作区的代码，还没有 add，我们有两种做法，一种是直接手动删除，但这种做法不太推荐，因为假设你已经对一段代码编写了三天保存，然后这次你再进行修改，如果说你想回退到修改前的版本，你可能不会确定你修改了哪些，因此，我们还是建议用第二种方法git checkout -- [file]来修改。

情况⼆：已经 add ，但没有 commit

add后还是保存到了暂存区呢？怎么撤销呢?

        让我们来回忆⼀下学过的 git reset 回退命令，该命令如果使⽤--mixed 参数，可以将暂存区 的内容退回为指定的版本内容，但⼯作区⽂件保持不变。那我们就可以回退下暂存区的内容了！！！ ⽰例如下：

情况三：已经 add ，并且也 commit 了

        我们可以 git reset --hard HEAD^ 回退到上⼀个版本！不过，这是有条件的，就是 你还没有把⾃⼰的本地版本库推送到远程。还记得Git是分布式版本控制系统吗？我们后⾯会讲到远程 版本库，⼀旦你推送到远程版本库，你就真的惨了……

具体效果如图所示：

10、删除文件

        在Git中，删除也是⼀个修改操作，我们实战⼀下,如果要删除file5，怎样操作呢？

方法一：直接rm file5 ，但这样直接删除是没有⽤的，反⽽徒增烦恼，此时，⼯作区和版本库就不⼀致了，要删⽂件，⽬前除了要删⼯作区的⽂件，还要清除版本库的⽂件。

        ⼀般⾛到这⾥，有两种可能:

                1.确实要从版本库中删除该⽂件

                2.不⼩⼼删错了

对第⼆种情况，很明显误删，需要使⽤ git checkout -- [file]来进⾏恢复，很简单,我们刚学过（删除也是修改）。

对于第⼀种情况，很明显是没有删完，我们只删除了⼯作区的⽂件。这时就需要使⽤ git rm 将⽂ 件从暂存区和⼯作区中删除，并且 commit ：

方法二：直接实用 git rm file4 通过用例可以看出，上面的方法一显然多此一举，所以说建议直接使用方法二。

11、分支管理

（1）理解分⽀

        本章开始介绍 Git 的杀⼿级功能之⼀（注意是之⼀，也就是后⾯还有之⼆，之三……）：分⽀。分⽀就 是科幻电影⾥⾯的平⾏宇宙，当你正在电脑前努⼒学习 C++ 的时候，另⼀个你正在另⼀个平⾏宇宙⾥ 努⼒学习 JAVA。

        如果两个平⾏宇宙互不⼲扰，那对现在的你也没啥影响。不过，在某个时间点，两个平⾏宇宙合并 了，结果，你既学会了 C++ ⼜学会了 JAVA！

        在版本回退⾥，你已经知道，每次提交，Git都把它们串成⼀条时间线，这条时间线就可以理解为是⼀ 个分⽀。截⽌到⽬前，只有⼀条时间线，在Git⾥，这个分⽀叫主分⽀，即 master 分⽀。 再来理解⼀下HEAD，HEAD 严格来说不是指向提交，⽽是指向master，master才是指向提交的，所 以，HEAD 指向的就是当前分⽀。

        每次提交，master分⽀都会向前移动⼀步，这样，随着你不断提交，master分⽀的线也越来越⻓,⽽ HEAD只要⼀直指向master分⽀即可指向当前分⽀。

（2）创建分支

        Git ⽀持我们查看或创建其他分⽀，在这⾥我们来创建第⼀个⾃⼰的分⽀ dev ，对应的命令为：

        当我们创建新的分⽀后，Git 新建了⼀个指针叫 dev， * 表⽰当前 HEAD 指向的分⽀是 master 分 ⽀。另外，可以通过⽬录结构发现，新的 dev 分⽀：

（3）切换分支

        我们如何切换到dev 分⽀下进⾏开发呢？使⽤ git checkout 命令即可完成切换，⽰例如下：

我们发现 HEAD 已经指向了 dev，就表⽰我们已经成功的切换到了 dev 上！ 接下来，在 dev 分⽀下修改 file3⽂件，新增⼀⾏内容，并进⾏⼀次提交操作：

现在，dev 分⽀的⼯作完成，我们就可以切换回 master 分⽀：

切换回 master 分⽀后，发现ReadMe⽂件中新增的内容不⻅了！！！

在 dev 分⽀上，内容还在。为什么会出现这个现象呢？我们来看看 dev 分⽀和 master 分⽀指向，发 现两者指向的提交是不⼀样的：

看到这⾥就能明⽩了，因为我们是在dev分⽀上提交的，⽽master分⽀此刻的提交点并没有变，此时的状态如图如下所⽰。

（4）合并分支

为了在 master 主分⽀上能看到新的提交，就需要将 dev 分⽀合并到 master 分⽀，⽰例如下：

git merge 命令⽤于合并指定分⽀到当前分⽀。合并后，master 就能看到 dev 分⽀提交的内容 了。此时的状态如图如下所⽰：

Fast-forward 代表“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度⾮常快。 当然，也不是每次合并都能 Fast-forward，我们后⾯会用到其他⽅式的合并

（5）删除分支

        合并完成后, dev 分⽀对于我们来说就没⽤了， 那么dev分⽀就可以被删除掉，注意如果当前正处于某 分⽀下，就不能删除当前分⽀，如：

        ⽽可以在其他分⽀下删除当前分⽀，如：

（6）合并冲突

        可是，在实际分⽀合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。 为了演⽰这问题，创建⼀个新的分⽀ dev1 ，并切换⾄⽬标分⽀，我们可以使⽤ git checkout - b dev1 ⼀步完成创建并切换的动作，在 dev1 分⽀下修改 file3⽂件，更改⽂件内容如下，并进⾏⼀次提交，⽰例如下：

切换⾄ master 分⽀，观察 file3⽂件内容，我们发现，切回来之后，⽂件内容由变成了⽼的版本，这种现象很正常，我们现在也完全能理解。 此时在 master 分⽀上，我们对 ReadMe ⽂件再进⾏⼀次修改，并进⾏提交，如下：

        现在，master分支和dev1分⽀各⾃都分别有新的提交，变成了这样：

这种情况下，Git 只能试图把各⾃的修改合并起来，但这种合并就可能会有冲突，如下所⽰：

        发现 file3⽂件有冲突后，可以直接查看⽂件内容，要说的是 Git 会⽤ >>>>>> 来标记出不同分⽀的冲突内容，如下所⽰：

        此时我们必须要⼿动调整冲突代码，并需要再次提交修正后的结果！！（再次提交很重要，切勿忘 记）

到这⾥冲突就解决完成，此时的状态变成了

⽤带参数的 git log也可以看到分⽀的合并情况，具体⼤家可以⾃⾏搜索 git log 的⽤法:

最后，不要忘记 dev1 分⽀使⽤完毕后就可以删除了。

（7）分⽀管理策略

        通常合并分⽀时，如果可能，Git 会采⽤ Fast forward 模式。在这种 Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提交到底是 merge 进来的还是正常提交的。

        但在合并冲突部分，我们也看到通过解决冲突问题，会再进⾏⼀次新的提交，得到的最终状态为：

        那么这就不是 Fast forward 模式了，这样的好处是，从分⽀历史上就可以看出分⽀信息。例如我 们现在已经删除了在合并冲突部分创建的 dev1 分⽀，但依旧能看到 master 其实是由其他分⽀合并得到：

        Git ⽀持我们强制禁⽤ Fast forward 模式，那么就会在 merge 时⽣成⼀个新的 commit ，这样， 从分⽀历史上就可以看出分⽀信息。

        下⾯我们实战⼀下 --no-ff ⽅式的 git merge 。⾸先，创建新的分⽀ dev2 ，并切换⾄新的分⽀，修改 file3⽂件，并提交⼀个新的 commit:

切回 master 分⽀，开始合并:

        请注意 --no-ff 参数，表⽰禁⽤ Fast forward 模式。禁⽤ Fast forward 模式后合并会创建 ⼀个新的 commit ，所以加上 -m 参数，把描述写进去。

        所以在合并分⽀时，加上 --no-ff 参数就可以⽤普通模式合并，合并后的历史有分⽀，能看出来曾 经做过合并，⽽ fast forward 合并就看不出来曾经做过合并。

（8）分支策略

在实际开发中，我们应该按照⼏个基本原则进⾏分⽀管理：

        ⾸先，master分⽀应该是⾮常稳定的，也就是仅⽤来发布新版本，平时不能在上⾯⼲活；

        那在哪⼲活呢？⼲活都在dev分⽀上，也就是说，dev分⽀是不稳定的，到某个时候，⽐如1.0版本发布时，再把dev分⽀合并到master上，在master分⽀发布1.0版本；

        你和你的同事们每个⼈都在dev分⽀上⼲活，每个⼈都有⾃⼰的分⽀，时不时地往dev分⽀上合并就可以了。

（9）bug分支

        假如我们现在正在 dev2 分⽀上进⾏开发，开发到⼀半，突然发现 master 分⽀上⾯有 bug，需要解决。在Git中，每个 bug 都可以通过⼀个新的临时分⽀来修复，修复后，合并分⽀，然后将临时分⽀删除。

可现在 dev2 的代码在⼯作区中开发了⼀半，还⽆法提交，怎么办？例如：

         未提交的更改会跟随分支切换,示例如下：

        Git 提供了 git stash 命令，可以将当前的⼯作区信息进⾏储藏，被储藏的内容可以在将来某个时间恢复出来。

        ⽤ git status 查看⼯作区，就是⼲净的（除⾮有没有被 Git 管理的⽂件），因此可以放⼼地创建分 ⽀来修复bug。

        储藏 dev2 ⼯作区之后，由于我们要基于master分⽀修复 bug，所以需要切回 master 分⽀，再新 建临时分⽀来修复 bug，⽰例如下：

修复完成后，切换到 master 分⽀，并完成合并，最后删除 fix_bug 分⽀：

        ⾄此，bug 的修复⼯作已经做完了，我们还要继续回到 dev2 分⽀进⾏开发。切换回 dev2 分⽀，⼯作区是⼲净的，刚才的⼯作现场存到哪去了？⽤ git stash list 命令看看：

        ⼯作现场还在，Git 把 stash 内容存在某个地⽅了，但是需要恢复⼀下，如何恢复现场呢？我们可以使 ⽤ git stash pop 命令，恢复的同时会把 stash 也删了，⽰例如下：

        另外，恢复现场也可以采⽤ git stash apply 恢复，但是恢复后，stash内容并不删除，你需要 ⽤ git stash drop 来删除；

        你可以多次stash，恢复的时候，先⽤ git stash list 查看，然后恢复指定的stash，⽤命令 git stash apply stash@{0} ,这部分⾃⾏使⽤。

但我们注意到了，修复 bug 的内容，并没有在 dev2 上显⽰。

        master 分⽀⽬前最新的提交，是要领先于新建 dev2 时基于的 master 分⽀的提交的，所以我们 在 dev2 中当然看不⻅修复 bug 的相关代码。

        我们的最终⽬的是要让 master 合并 dev2 分⽀的，那么正常情况下我们切回 master 分⽀直接合 并即可，但这样其实是有⼀定⻛险的。

        是因为在合并分⽀时可能会有冲突，⽽代码冲突需要我们⼿动解决（在 master 上解决）。我们⽆法 保证对于冲突问题可以正确地⼀次性解决掉，因为在实际的项⽬中，代码冲突不只⼀两⾏那么简单， 有可能⼏⼗上百⾏，甚⾄更多，解决的过程中难免⼿误出错，导致错误的代码被合并到 master 上。 

        解决这个问题的⼀个好的建议就是：最好在⾃⼰的分⽀上合并下 master ，再让 master 去合并 dev ，这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试，⽽不影响 master 。对应的实操演⽰如下:

1、dev 合并 master 并解决冲突、重新提交：

2、切回master 并合并dev2 --无需解决冲突

（10）强制删除分支

        在现实中有这么一种情况，产品经理会让你开发一项功能，然后你就需要创建一个分支来开发，在你开发一部分的时候在分支已经提交过，然后产品经理告诉你这一项目取消了，不用再继续了，这时候我们就需要删除该分支，我们会发现用以前的删除分支方法git branch -d会报错，演⽰如下：

直接使⽤传统的删除分⽀的⽅法不⾏，按照提⽰，有了如下⽅式:

（11）分支小结

        分⽀在实际中有什么⽤呢？假设你准备开发⼀个新功能，但是需要两周才能完成，第⼀周你写了50% 的代码，如果⽴刻提交，由于代码还没写完，不完整的代码库会导致别⼈不能⼲活了。如果等代码全 部写完再⼀次提交，⼜存在丢失每天进度的巨⼤⻛险。

        现在有了分⽀，就不⽤怕了。你创建了⼀个属于你⾃⼰的分⽀，别⼈看不到，还继续在原来的分⽀上 正常⼯作，⽽你在⾃⼰的分⽀上⼲活，想提交就提交，直到开发完毕后，再⼀次性合并到原来的分⽀ 上，这样，既安全，⼜不影响别⼈⼯作。

        并且 Git ⽆论创建、切换和删除分⽀，Git在1秒钟之内就能完成！⽆论你的版本库是1个⽂件还是1万个⽂件。

12、远程操作

（1）理解分布式版本控制系统

        我们⽬前所说的所有内容（⼯作区，暂存区，版本库等等），都是在本地！也就是在你的笔记本或者 计算机上。⽽我们的 Git 其实是分布式版本控制系统！什么意思呢？

        可以简单理解为，我们每个⼈的电脑上都是⼀个完整的版本库，这样你⼯作的时候，就不需要联⽹ 了，因为版本库就在你⾃⼰的电脑上。既然每个⼈电脑上都有⼀个完整的版本库，那多个⼈如何协作 呢？⽐⽅说你在⾃⼰电脑上改了⽂件A，你的同事也在他的电脑上改了⽂件A，这时，你们俩之间只需 把各⾃的修改推送给对⽅，就可以互相看到对⽅的修改了。

        分布式版本控制系统的安全性要⾼很多，因为每个⼈电脑⾥都有完整的版本库，某⼀个⼈的电脑坏掉 了不要紧，随便从其他⼈那⾥复制⼀个就可以了。

        在实际使⽤分布式版本控制系统的时候，其实很少在两⼈之间的电脑上推送版本库的修改，因为可能 你们俩不在⼀个局域⽹内，两台电脑互相访问不了。也可能今天你的同事病了，他的电脑压根没有开 机。因此，分布式版本控制系统通常也有⼀台充当“中央服务器”的电脑，但这个服务器的作⽤仅仅 是⽤来⽅便“交换”⼤家的修改，没有它⼤家也⼀样⼲活，只是交换修改不⽅便⽽已。有了这个“中央服务器”的电脑，这样就不怕本地出现什么故障了（⽐如运⽓差，硬盘坏了，上⾯的所有东西全部 丢失，包括git的所有内容）

（2）远程仓库

        Git 是分布式版本控制系统，同⼀个 Git 仓库，可以分布到不同的机器上。怎么分布呢？最早，肯定只 有⼀台机器有⼀个原始版本库，此后，别的机器可以 “克隆” 这个原始版本库，⽽且每台机器的版本 库其实都是⼀样的，并没有主次之分。

        你肯定会想，⾄少需要两台机器才能玩远程库不是？但是我只有⼀台电脑，怎么玩？

        其实⼀台电脑上也是可以克隆多个版本库的，只要不在同⼀个⽬录下。不过，现实⽣活中是不会有⼈ 这么傻的在⼀台电脑上搞⼏个远程库玩，因为⼀台电脑上搞⼏个远程库完全没有意义，⽽且硬盘挂了 会导致所有库都挂掉，所以我也不告诉你在⼀台电脑上怎么克隆多个仓库。

        实际情况往往是这样，找⼀台电脑充当服务器的⻆⾊，每天24⼩时开机，其他每个⼈都从这个“服务 器”仓库克隆⼀份到⾃⼰的电脑上，并且各⾃把各⾃的提交推送到服务器仓库⾥，也从服务器仓库中 拉取别⼈的提交。

        完全可以⾃⼰搭建⼀台运⾏ Git 的服务器，不过现阶段，为了学 Git 先搭个服务器绝对是⼩题⼤作。好 在这个世界上有个叫 GitHub 的神奇的⽹站，从名字就可以看出，这个⽹站就是提供 Git 仓库托管服务 的，所以，只要注册⼀个GitHub账号，就可以免费获得 Git 远程仓库。

        github 是国外的⽹站，速度⽐较慢，我们课堂上同统⼀采⽤码云来托管代码。下来，我们从零开始， 使⽤⼀下码云远程仓库。

1.新建远程仓库

2.填写基本信息

        注意：该模板只是演示，具体信息根据个人需求可自行修改。

创建成功

创建成功后，我们可以对远程仓库进⾏⼀个基本的设置：开源or私有

从创建好的远程仓库中我们便能看到，之前在本地学习过的分⽀，也存在于远程仓库中并被管理起来 了。刚创建的仓库有且只有⼀个默认的master分⽀

3.克隆远程仓库

克隆/下载远端仓库到本地，需要使⽤ git clone 命令，后⾯跟上我们的远端仓库的链接，远端仓库 的链接可以从仓库中找到：选择“克隆/下载”获取远程仓库链接：

SSH 协议和 HTTPS 协议是 Git 最常使⽤的两种数据传输协议。SSH 协议使⽤了公钥加密和公钥登陆机 制，体现了其实⽤性和安全性，使⽤此协议需要将我们的公钥放上服务器，由 Git 服务器进⾏管理。使 ⽤ HTTPS ⽅式时，没有要求，可以直接克隆下来。

使⽤ HTTPS ⽅式：

使⽤ SSH ⽅式:

使⽤ SSH ⽅式克隆仓库，由于我们没有添加公钥到远端库中，服务器拒绝了我们的 clone 链接。需要 我们设置⼀下：

        第⼀步：创建SSH Key。在⽤⼾主⽬录下，看看有没有.ssh⽬录，如果有，再看看这个⽬录下有没有 id_rsa 和 id_rsa.pub 这两个⽂件，如果已经有了，可直接跳到下⼀步。如果没有，需要创建 SSH Key：(我这里是没有的需要创建)

        顺利的话，可以在⽤⼾主⽬录⾥找到 .ssh ⽬录，⾥⾯有 id_rsa 和 id_rsa.pub 两个⽂件，这两 个就是SSH Key的秘钥对， id_rsa 是私钥，不能泄露出去， id_rsa.pub 是公钥，可以放⼼地告 诉任何⼈。

第⼆步：添加⾃⼰的公钥到远端仓库。

点击 ssh公钥 选项，进⾏设置：

        点击确认后，需要对你进⾏认证，输⼊你的账号密码即可。⾄此，我们的准备⼯作全部做完，欢快的 clone吧。

        done, 成功！如果有多个⼈协作开发，GitHub/Gitee 允许添加多个公钥，只要把每个⼈的电脑上的 Key 都添加到 GitHub/Gitee，就可以在每台电脑上往 GitHub/Gitee 上提交推送了。 当我们从远程仓库克隆后，实际上 Git 会⾃动把本地的 master 分⽀和远程的 master 分⽀对应起来， 并且，远程仓库的默认名称是 origin 。在本地我们可以使⽤ git remote 命令，来查看远程库的信息，或者，⽤ git remote -v 显⽰更详细的信息如：

        上⾯显⽰了可以抓取和推送的origin的地址。如果没有推送权限，就看不到 push 的地址。推送是什么 意思呢，我们继续往下看。

4.向远程仓库推送

        提交时要注意，如果我们之前设置过全局的 name 和 e-mail，这两项配置需要和 gitee 上配置的⽤⼾ 名和邮箱⼀致，否则会出错。或者从来没有设置过全局的 name 和 e-mail，那么我们第⼀次提交时也会报错。这就需要我们重新配置下了，同样要注意需要和 gitee 上配置的⽤⼾名和邮箱⼀致。如何配置 已讲过，在这⾥就不再赘述。

        到这⾥我们已经将内容提交⾄本地仓库中，如何将本地仓库的内容推送⾄远程仓库呢，需要使⽤ git push 命令， 该命令⽤于将本地的分⽀版本上传到远程并合并，命令格式如下：

git push <远程主机名> <本地分⽀名>:<远程分⽀名>
# 如果本地分⽀名与远程分⽀名相同，则可以省略冒号：
git push <远程主机名> <本地分⽀名>

        本地已经 clone 成功远程仓库后，我们便可以向仓库中提交内容，例如新增⼀个 file.txt ⽂件：

推送成功！这⾥由于我们使⽤的是 SSH 协议，是不⽤每⼀次推送都输⼊密码的，⽅便了我们的推送操作。如果你使⽤的是 HTTPS 协议，有个⿇烦地⽅就是每次推送都必须输⼊⼝令。

接下来，看看码云远端：

5.拉取远程仓库

在 gitee 上点击 README.md ⽂件并在线修改它:

        此时，远程仓库是要领先于本地仓库⼀个版本，为了使本地仓库保持最新的版本，我们需要拉取下远 端代码，并合并到本地。Git 提供了 git pull 命令，该命令⽤于从远程获取代码并合并本地的版 本。格式如下：

git pull <远程主机名> <远程分⽀名>:<本地分⽀名>
# 如果远程分⽀是与当前分⽀合并，则冒号后⾯的部分可以省略。
git pull <远程主机名> <远程分⽀名>

6.配置 Git

忽略特殊⽂件

        在⽇常开发中，我们有些⽂件不想或者不应该提交到远端，⽐如保存了数据库密码的配置⽂件，那怎 么让 Git 知道呢？在 Git ⼯作区的根⽬录下创建⼀个特殊的 .gitignore ⽂件，然后把要忽略的⽂件 名填进去，Git 就会⾃动忽略这些⽂件了。

        不需要从头写 .gitignore ⽂件，gitee 在创建仓库时就可以为我们⽣成，不过需要我们主动勾选⼀ 下：

        如果当时没有选择这个选择，在⼯作区创建⼀个也是可以的。⽆论哪种⽅式，最终都可以得到⼀个完 整的 .gitignore ⽂件，例如我们想忽略以 .so 和 .ini 结尾所有⽂件， .gitignore 的内容 如下：

# 省略选择模本的内容
...
# My configurations:
*.ini
*.so

        在 .gitignore ⽂件中也可以指定某个确定的⽂件。 最后⼀步就是把 .gitignore 也提交到远端，就完成了。

gitignore规则：

# 排除所有.开头的隐藏⽂件:
.*
# 不排除.gitignore
!.gitignore

给命令配置别名

        在我们使⽤ Git 期间，有些命令敲的时候着实让⼈头疼（太⻓了。。），幸运的是，git⽀持对命令进⾏简化！

举个例⼦，将 git status 简化为 git st ，对应的命令为：

 git config --global alias.st status

        --global 参数是全局参数，也就是这些命令在这台电脑的所有Git仓库下都有⽤。如果不加，那只 针对当前的仓库起作⽤。

13、标签管理

(1)理解标签

        标签 tag ，可以简单的理解为是对某次 commit 的⼀个标识，相当于起了⼀个别名。例如，在项⽬ 发布某个版本的时候，针对最后⼀次 commit 起⼀个 v1.0 这样的标签来标识⾥程碑的意义。

        这有什么⽤呢？相较于难以记住的 commit id ， tag 很好的解决这个问题，因为 tag ⼀定要给⼀ 个让⼈容易记住，且有意义的名字。当我们需要回退到某个重要版本时，直接使⽤标签就能很快定位到。

(2)创建标签

在Git中打标签⾮常简单，⾸先，切换到需要打标签的分⽀上，然后，敲命令 git tag [name] 就可以打⼀个新标签，可以⽤命令 git tag 查看所有标签：

        默认标签是打在最新提交的 commit 上的。那如何在指定的commit上打标签呢？⽅法是找到历史提 交的commit id，然后打上就可以了，⽰例如下：

注意，标签不是按时间顺序列出，⽽是按字⺟排序的。

可以⽤ git show [tagname] 查看标签信息。

Git 还提供可以创建带有说明的标签，⽤-a指定标签名，-m指定说明⽂字，格式为：

git tag -a [name] -m "XXX" [commit_id]

        另外，打完标签之后，使⽤ tree .git 命令查看⼀下你的本地库有什么变化，肯定能帮助你理解！

(3)操作标签

如果标签打错了，也可以删除：

        因为创建的标签都只存储在本地，不会⾃动推送到远程。所以，打错的标签可以在本地安全删除。 如果要推送某个标签到远程，使⽤命令 git push origin

此时，查看远端码云，看到了标签已经被更新！完美！

当然，如果你本地有很多标签，也可以⼀次性的全部推送到远端:

git push origin --tags

如果标签已经推送到远程，要删除远程标签就⿇烦⼀点，先从本地删除，然后，从远程删除。删除命令也是push，但是格式如下：

在码云上查看确实删除成功：