【Git基础】常用git命令（一）

文章目录

1. 创建仓库

1.1 创建仓库

在本地创建仓库

在本地创建Git仓库非常简单，只需要在命令行中进入要作为仓库的目录，然后执行以下命令：

git init

这样就会在当前目录下创建一个空的Git仓库，这个时候会在仓库目录下多了一个.git目录，.git目录里由很多关于git管理的文件，这里面的东西我们不用管。

有了仓库之后，就可以使用git add和git commit像仓库中添加要跟踪的文件，和提交修改的内容了。

在GitHub上创建仓库

GitHub是一个非常流行的代码托管平台，可以在上面创建公开或私有仓库来管理代码。创建仓库的步骤如下：

登录GitHub账号
点击右上角的加号，选择“New repository”
输入仓库名称、描述、可见性等信息
点击“Create repository”

创建成功后，可以通过Git命令将本地代码上传到GitHub仓库中。

在GitLab上创建仓库

GitLab是另一个流行的代码托管平台，也可以在上面创建公开或私有仓库来管理代码。创建仓库的步骤如下：

登录GitLab账号
点击左侧菜单栏中的“New project”
输入仓库名称、描述、可见性等信息
点击“Create project”

创建成功后，可以通过Git命令将本地代码上传到GitLab仓库中。

1.2 git add和git commit

① git add

它用于将工作目录中的文件和修改添加到Git暂存区中，准备提交到Git仓库中。Git add命令的作用是将修改的代码标记为“已修改”，以便后续提交到Git仓库中。

Git add命令有以下几种使用方式：

添加单个文件

git add <file>

其中，<file>是要添加到暂存区的文件名。例如，要将hello.txt文件添加到Git暂存区中，可以执行以下命令：

git add hello.txt

添加多个文件

git add <file1> <file2> ...

可以同时添加多个文件，例如：

git add hello.txt world.txt

添加所有文件

git add .

或

git add *

这个命令会将当前目录下的所有文件添加到Git暂存区中。

这两者的区别在于：

git add .只会将当前目录下的所有文件和文件夹添加到暂存区，不包括以.开头的隐藏文件。
git add *会将当前目录下的所有文件和文件夹添加到暂存区，包括以.开头的隐藏文件。

因此，在使用 git add 命令时，推荐使用git add .，以避免不必要的文件和文件夹被添加到暂存区。

git add <directory>

可以添加某个目录下的所有文件，例如：

git add src/

需要注意的是，执行git add命令只会将修改的代码添加到Git暂存区中，还需要执行git commit命令将修改的代码提交到Git仓库中。如果不执行git commit命令，暂存区中的修改将不会保存到Git仓库中。

总之，Git add命令是Git版本控制系统中非常重要的一个命令，它可以帮助开发者有效地管理代码修改记录，保证代码的可追溯性和可维护性。

② git commit

它用于将本地工作目录中的修改记录提交到本地仓库中。在执行git commit命令时，需要指定提交的信息，这个信息通常包括修改的描述和作者等信息，同时可以添加一些标签和注释。

Git commit命令的使用方法如下：

git commit -m "commit message"

其中，-m选项用于指定提交的信息，可以是任意文本，但最好是简明扼要的描述。执行完该命令后，Git会将所有已经暂存的修改记录提交到本地仓库中，并生成一个唯一的提交ID。这个ID可以用来查看提交记录、回滚修改等操作。

除了-m选项外，还可以使用其他选项来指定提交的内容、作者、时间等信息，例如：

git commit -a -m "commit message"  # 提交所有已经跟踪的文件
git commit --amend -m "new commit message"  # 修改最近一次提交的信息

总之，Git commit是Git版本控制系统中非常重要的一个命令，它可以帮助开发者有效地管理代码修改记录，保证代码的可追溯性和可维护性。

③ 工作区、暂存区和仓库

在 Git 中，有三个重要的概念：工作区、暂存区和仓库。

工作区：是指我们实际操作的目录，也就是我们常说的项目目录，在这里我们可以添加、修改、删除文件。
暂存区：也叫索引或者缓存区，是一个临时存放我们修改的文件的地方，Git 会将我们修改的文件存放在这里，等待我们执行 git commit 命令将它们提交到仓库中。
仓库：也叫版本库，是存放 Git 项目的所有版本的地方，它包含了我们提交到暂存区的所有文件，以及每次提交时的相关信息（如提交人、提交时间、提交信息等）。

Git 的工作流程是这样的：我们在工作区中添加、修改、删除文件，然后使用 git add 命令将修改的文件添加到暂存区，最后使用 git commit 命令将暂存区的文件提交到仓库中。这样，我们就可以在仓库中保存我们的项目版本，并可以方便地进行版本控制和管理。
在这里插入图片描述

2. 创建git服务器

2.1 服务器：

创建一个文件夹，并且在文件夹内使用：

git init --bare

在这里插入图片描述

这样我们就在服务器上创建了一个裸仓库，下面简单介绍一下裸仓库：

裸仓库就是一个没有工作区的仓库，它只包含 Git 数据库中的版本信息，没有实际的文件内容，因此也不支持进行文件修改和提交操作。它通常用于搭建远程服务器，用于代码的共享和管理。

裸仓库与普通的 Git 仓库不同之处在于，它没有工作区，因此不包含项目实际的文件内容，只包含 Git 数据库中的版本信息。这使得裸仓库更加轻量级，占用空间更小，同时更加适合用于多人协作开发和代码共享。

使用git init --bare命令创建裸仓库时，需要指定一个目录作为仓库的存储路径。执行完该命令后，Git 会在指定的路径下创建一个裸仓库，并在其中生成一些必要的文件和目录，如 HEAD、refs、objects 等。此时，裸仓库已经可以被其他开发者克隆和拉取代码。

在使用裸仓库时，通常需要进行以下操作：

克隆仓库：其他开发者可以使用 git clone 命令克隆裸仓库到本地进行开发和管理
拉取代码：其他开发者可以使用 git pull 命令从裸仓库中拉取最新的代码
推送代码：其他开发者可以使用 git push 命令将本地代码推送到裸仓库中进行共享和管理。

裸仓库的使用需要谨慎，因为它没有工作区，所以不支持进行文件修改和提交操作。同时，裸仓库中的所有操作都是针对 Git 数据库的操作。

2.2 本地

首先我们需要使用 SSH 协议进行操作，步骤如下：

生成 SSH 密钥：使用 ssh-keygen 命令生成 SSH 密钥，命令格式为：
```
ssh-keygen -t rsa -C "[email protected]"
```
其中，-t 参数表示密钥类型，这里使用 RSA；-C 参数表示注释，可以填写个人邮箱地址，也可以忽略不填。
将公钥添加到远程服务器：将生成的公钥（默认存储在 C:/Users/[用户名]/.ssh/id_rsa.pub 文件中）添加到远程服务器中，以便进行认证，存储在服务器的~/.ssh/authorized_keys中。
配置 SSH 代理：使用 ssh-agent 命令启动 SSH 代理，并将生成的私钥添加到代理中，命令格式为：
```
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa
```
这样可以避免每次进行 Git 操作时都需要输入密码。
在 Git 中使用 SSH 协议：在 Git 中使用 SSH 协议进行操作时，需要将远程服务器的地址改为 SSH 协议的地址，格式为：
```
git ssh://<user_name>@<server_address>:<repository_path>
```
其中，server_address 表示远程服务器的地址，repository_path 表示仓库的路径。
例如将服务器中的仓库克隆下来：
```
git clone ssh://root@<server_address>:/root/learn-git
```

在使用 SSH 协议进行操作时，需要注意保护好私钥，避免泄露。同时，如果无法通过 SSH 协议进行操作，可以尝试使用 HTTPS 协议进行操作。

2.3 修改配置信息

git config 是 Git 中用于设置和读取配置信息的命令，可以用于设置 Git 的全局或局部配置、读取 Git 的配置信息等。

常用的 git config 命令包括：

git config --global user.name "your_name"：设置 Git 的全局用户名。
git config --global user.email "[email protected]"：设置 Git 的全局邮箱地址。
git config --global core.editor "your_editor"：设置 Git 的全局文本编辑器。
git config --global color.ui true：启用 Git 的全局颜色输出。
git config --list：列出 Git 的所有配置信息。
git config --unset key：删除 Git 的指定配置信息。
git config --unset-all key：删除 Git 的所有指定配置信息。

其中，–global 参数表示全局配置，即该配置适用于当前用户的所有 Git 仓库。如果不使用 --global 参数，则表示局部配置，只适用于当前仓库。

可以通过以下命令来查看 Git 的配置信息：

git config --list

输出结果包含 Git 的所有配置信息，包括用户名、邮箱地址、文本编辑器、颜色输出等。如果需要修改配置信息，可以使用 git config 命令重新设置即可。

前两个用户名跟邮箱地址是必须要进行配置的，它会显示在每次提交中。

3. git基础原理

在这里插入图片描述

3.1 四个区域

Workspace：工作区，就是平时存放项目代码的地方
Index/Stage：暂存区，用于临时存放改动，事实上它只是一个文件，保存即将提交的文件列表信息
Repository：仓库区或版本库，就是安全存放数据的位置，这里面有提交的所有版本的数据，其中HEAD指向最新放入仓库的版本
Remote：远程仓库，托管代码的服务器，可以简单的认为是项目组中的一台电脑用于远程数据交换

3.2 工作流程

在工作目录中添加、修改文件
将需要进行版本管理的文件add到暂存区域
将暂存区域的文件commit到git仓库
本地的修改push到远程仓库，如果失败则执行第5步
git pull将远程仓库的修改拉取到本地，如果有冲突需要修改冲突，回到第三步

因此，git管理的文件有三种状态：已修改（modified）,已暂存（staged）,已提交(committed)

3.3 文件的四种状态

在这里插入图片描述

在Git中，可以使用git status命令查看当前文件的状态，其中红色表示文件被修改但未暂存，绿色表示文件已经被暂存但未提交，而没有颜色表示文件没有修改。通过这些状态，我们可以清楚地了解文件的变化情况，方便我们进行版本控制。

Untracked：未跟踪, 此文件在文件夹中，但并没有加入到git库，不参与版本控制，通过git add 状态变为Staged
Unmodify：文件已经入库且未修改，即版本库中的文件快照内容与文件夹中完全一致，这种类型的文件有两种去处，如果它被修改，而变为Modified，如果使用git rm移出版本库，则成为Untracked文件
Modified：文件已修改，仅仅是修改，并没有进行其他的操作，这个文件也有两个去处，通过git add可进入暂存staged状态，使用git checkout则丢弃修改，返回到unmodify状态，这个git checkout即从库中取出文件，覆盖当前修改
Staged：暂存状态，执行git commit则将修改同步到库中，这时库中的文件和本地文件又变为一致，文件为Unmodify状态

① git rm

git rm命令可以用于将文件从Git仓库中删除。它有两种用法：

git rm <file>：将指定文件从Git仓库中删除，并将删除操作添加到暂存区中。
git rm --cached <file>：将指定文件从Git仓库中删除，但是不删除本地文件，只将删除操作添加到暂存区中。

使用git rm命令删除文件后，需要通过git commit命令提交暂存区中的修改，才能将文件从Git仓库中彻底删除。

需要注意的是，如果删除的文件已经被其他人修改并提交到了仓库中，那么在你的本地使用git rm命令删除该文件后，再将修改推送到远程仓库时会产生冲突。此时需要通过合并操作解决冲突。

② git checkout

git checkout命令可以用于切换分支、回滚代码和撤销修改。它有以下几种用法：

切换分支：git checkout <branch>，将当前工作目录切换到指定的分支。
回滚代码：git checkout <commit> .，将当前工作目录中的所有文件回滚到指定的提交版本。
撤销修改：git checkout -- <file>，将指定文件恢复到最近一次提交的状态。
创建新分支：git checkout -b <new_branch>，创建一个新的分支并切换到该分支。

需要注意的是，使用git checkout命令切换分支或者回滚代码时，会清空当前工作目录中的所有未提交的修改。如果需要保存修改，需要先将修改暂存或提交到仓库中。

4.优雅的提交你的修改

4.1 git commit命令详解

git commit file1.name file2.name file3.name .. –m “commit messages”：commit指提交修改到本地的仓库里，file*.name指的是带commit的文件 –m后面的内容指提交的信息，即备注
git commit –a –m “commit messeages”：添加的-a参数会把当前暂存区里所有的修改（包括删除操作）都提交，但是那些尚未添加到暂存区的内容是不会提交的，网上有很多的博客内容说-a参数会把尚未add的文件也提交了，这个说法是错误的。
git commit：我们可能由时候手抖忘记输入-m参数，直接输入了git commit，于是出现了下面这个界面，即打开了一个vim编辑界面，敲入“i”键后保存，输入要添加的message后，输入“ESC”按键退出编辑界面，然后再敲入“:wqa”后会保存message内容，并且提交此次修改，如果敲入“:q”会取消这次提交。
git commit --amend：这也是我们经常用的命令，他会把此次提交追加到上一次的commit内容里。

4.2 git commit的格式

Angular 团队制定了一系列规范，以帮助开发者更好地使用 Git 进行 Angular 项目的开发。以下是其中的一些规范：

分支命名规范

feature/xxx：表示新增功能的分支，xxx 为功能名称；
bugfix/xxx：表示修复 bug 的分支，xxx 为 bug 名称；
hotfix/xxx：表示紧急修复的分支，xxx 为修复名称；
release/xxx：表示发布版本的分支，xxx 为版本号；
refactor/xxx：表示重构代码的分支，xxx 为重构名称；
docs/xxx：表示文档修改的分支，xxx 为文档名称；
test/xxx：表示测试用例的分支，xxx 为测试名称。

提交信息规范

每次提交代码时，需要遵循以下格式：

<type>(<scope>): <subject>
<BLANK LINE> 
<body> 
<BLANK LINE> 
<footer>

除了空白行<BLANCK LINE>，其余的三个分别对应：

<type>(<scope>): <subject>标题行，必填, 描述主要修改类型和内容
<body>：主题内容，描述为什么修改, 做了什么样的修改, 以及开发的思路等等
<footer>：页脚注释，放 Breaking Changes 或 Closed Issues

其中，type 表示提交类型，可以是：

feat：新特性
fix：修改问题
refactor：代码重构
docs：文档修改
style：代码格式修改, 注意不是 css 修改
test：测试用例修改
chore：其他修改, 比如构建流程, 依赖管理

scope表示commit 影响的范围，即影响的模块或者组件，比如: route, component, utils, build…
subject表示commit 的概述, 建议符合 50/72 formatting
body表示commit 具体修改内容, 可以分为多行, 建议符合 50/72 formatting
footer表示一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接，或者feature等等其余的信息

版本号规范

Angular 团队采用 SemVer（语义化版本号）规范，即 MAJOR.MINOR.PATCH，其中：

MAJOR：主版本号，表示不兼容的 API 变化；
MINOR：次版本号，表示向后兼容的新特性；
PATCH：修订号，表示向后兼容的 bug 修复。

合并请求规范

每次提交合并请求时，需要遵循以下格式：

[<type>(<scope>)]: <subject>

其中，type、scope、subject 与提交信息规范相同。

以上是 Angular 团队制定的一些规范，遵守这些规范可以提高团队协作效率，降低代码维护成本。

还可以使用git cmmit模板来规范提交

在~/.gitconfig文件里添加

[commit]
              template=~/.gitmessage

添加~/.gitmessage文件。例如，一个提交信息可能如下所示：
```
feat(login): add remember me feature

Add a remember me checkbox on the login page to allow users to stay logged in between sessions.

Fixes #123
```
这个提交信息中的 <type> 为 feat，表示新增功能，<scope> 为 login，表示影响的范围为登录模块，<subject> 为 add remember me feature，表示简要描述为新增记住我功能。<body> 描述了详细的修改内容，<footer> 中的 Fixes #123 表示关联了 issue #123。

4.3 git的commitizen

下载对应版本的nodejs包，并安装
使用 npm 工具进行全局安装
然后在项目目录里，运行下面命令，使其支持 Angular 的 Commit message 格式
如果我们希望每个使用 git 的项目都遵循这个标准，可以使用下面命令进行全局设置
创建一个 .czrc 文件在你的 home 目录，并将 path 指向上面所安装的 commitizen 适配器
现在我们可以在每个 git 项目中使用 git cz 提交我们的 commit message 了，当然我们还可以配置Commitlint做自动检测，检查不通过的可以拒绝提交，比较绝吧。
如果我们所有的commit信息都是按照这个格式填写的，在发布版本时，我们就可以使用以下命令生成changelog了

4.4 推送到远程分支

git push命令用于将本地分支的更新，推送到远程主机。它的格式与git pull命令相仿

git push <远程主机名> <本地分支名>:<远程分支名>

注意，分支推送顺序的写法是<来源地>:<目的地>，所以git pull是<远程分支>:<本地分支>，而git push是<本地分支>:<远程分支>。例如：

git push origin master：refs/for/master

如果省略远程分支名，则表示将本地分支推送与之存在”追踪关系”的远程分支(通常两者同名)，如果该远程分支不存在，则会被新建：

git push origin master

上面命令表示，将本地的master分支推送到origin主机的master分支。如果后者不存在，则会被新建。
在这里插入图片描述

如果省略本地分支名，则表示删除指定的远程分支，因为这等同于推送一个空的本地分支到远程分支：

git push origin :master # 等同于 git push origin --delete master

上面命令表示删除origin主机的master分支。

如果当前分支与远程分支之间存在追踪关系，则本地分支和远程分支都可以省略：

git push origin

上面命令表示，将当前分支推送到origin主机的对应分支。

如果当前分支只有一个追踪分支，那么主机名都可以省略：

git push

除了上述基本用法外，Git push 命令还有一些其他的选项，例如：

--force：强制推送本地分支，即覆盖远程分支；
--tags：推送本地标签到远程代码库；
--all：推送本地所有分支到远程代码库。

需要注意的是，git push命令会将本地的提交推送到远程代码库中，因此推荐在推送前先将本地代码库中的修改提交到本地仓库中。

4.5 git push冲突解决

产生冲突的情况通常是因为本地分支和远程分支的代码不一致，导致无法直接合并。具体情况如下：

本地分支和远程分支同时修改了同一文件的同一部分。
本地分支和远程分支都修改了同一文件，但是修改的部分不同，此时 Git 可以自动合并。
本地分支和远程分支都删除了同一个文件，此时 Git 无法自动合并。
本地分支和远程分支都新建了同一个文件，此时 Git 可以自动合并。

在这里插入图片描述

当发生冲突时，Git 会提示用户进行手动解决冲突。用户需要根据提示对冲突进行解决，然后再次提交代码。如果多个人同时修改了同一个文件的同一部分，那么需要协商好谁来解决冲突，或者每个人都在自己的本地分支上解决冲突，然后再合并到主分支上。

git解决冲突的步骤如下：

首先调用git pull去拉取分支下来：
然后会在冲突的文件里记录冲突的内容，head表示当前分支的内容，相面那个hash值表示当前远程仓库中的内容：
手动去解决冲突：
保存修改后的文件
执行git add命令，把修改后的文件添加到暂存区
执行git commit命令，提交修改
执行git push，提交到远程仓库

如果在执行git commit命令时，出现类似如下的提示：

Automatic merge failed; fix conflicts and then commit the result.

说明还有未解决的冲突，需要继续解决冲突，重复上述步骤，直到所有冲突都解决完毕。

如果不想解决冲突，可以使用git merge --abort命令取消合并。

在其他分支拉取查看：
在这里插入图片描述

可视化展示：
在这里插入图片描述

5. 补充：git push与git pull的区别

5.1 git push

基本格式：

git push [远程仓库名称] [本地分支名称]:[远程分支名称]

需要注意的事项：

远程仓库名称：通常为 origin，表示远程仓库的别名
本地分支名称：需要推送的本地分支
远程分支名称：推送到远程仓库的分支

在大多数情况下，可以使用简化的格式：

git push

该命令会将当前活动分支推送到与之关联的远程分支。

5.2 git pull

基本格式：

git pull [远程仓库名称] [远程分支名称]:[本地分支名称]

需要注意的事项：

远程仓库名称：通常为 origin，表示远程仓库的别名
远程分支名称：需要从远程仓库拉取的分支
本地分支名称：将拉取的远程分支合并到本地分支。

在大多数情况下，可以使用简化的格式：

git pull

该命令会将当前活动分支关联的远程分支拉取并合并到本地分支。

5.3 注意点

确保已经配置了远程仓库，通常使用git remote add [远程仓库名称] [远程仓库地址]添加远程仓库。
在推送之前，请确保已将本地分支与远程分支关联，可以使用git branch --set-upstream-to=[远程仓库名称]/[远程分支名称] [本地分支名称]关联分支。
在拉取之前，请确保本地工作区和暂存区是干净的，以避免合并冲突。如果有未提交的更改，可以先使用git stash保存更改，然后在拉取完成后使用git stash apply恢复更改。
如果遇到合并冲突，请仔细检查并解决冲突，然后提交更改。

5.4 名词解释及查看分支

远程仓库名称：远程仓库名称是用来表示远程 Git 仓库的一个简短名称。默认情况下，当你从远程仓库克隆一个项目时，远程仓库的名称会被设置为origin。你可以通过以下命令查看远程仓库名称：

git remote -v

这将列出所有的远程仓库及其对应的 URL。如果你想添加一个新的远程仓库，可以使用以下命令：

git remote add [远程仓库名称] [远程仓库地址]

远程分支名称：远程分支名称是在远程仓库中的一个分支的名称。通常，远程分支名称遵循[远程仓库名称]/[分支名称]的格式。例如，origin/master表示名为origin的远程仓库中的master分支。你可以通过以下命令查看所有远程分支：

git branch -r

本地分支名称：本地分支名称是在本地 Git 仓库中的一个分支的名称。你可以通过以下命令查看所有本地分支：

git branch

这将列出所有的本地分支，当前活动分支前会有一个星号（*）标识。

要查看本地分支与远程分支之间的关联关系，可以使用以下命令：

git branch -vv

这将显示每个本地分支及其关联的远程分支（如果有的话）。