git使用心得

git init

只需要使用一次
将该文件变为一个git可管理的仓库

git status

我们随时掌握工作区的情况，就要用到$ git status这个命令
- 工作区，暂存区，版本库和远程仓库
  - 修改的文件是在工作区
  - 我们要用add把它放到暂存区
  - 通过commit推到版本库
  - 最后通过push推送到远程仓库去
- 版本回退
  - 如果想要丢弃工作区的修改
    1
    $ git checkout -- 文件名
    - 可以将这个文件回退到上一个版本，即退回到最近一次add后commit的那个版本。
      - （本质上：$ git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。）
  - 如果已经提交到暂存区，想要把修改从暂存区撤回
    1. 用命令$ git reset HEAD <file>可以把暂存区的修改撤销掉，重新放回工作区
    2. 再用命令：$ git checkout -- file
  - 如果想要已经提交到版本库，想要回退版本
    - HEAD表示的是当前版本号，上一个版本就是HEAD^，上上一个版本就是HEAD^^，往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。
    1. ```
    $ git reset --hard HEAD^
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    
             命令表示返回到上一个版本
    
        
    
    ## git push
    
    ### 1.本地和远程仓库的关联
    
    1. ```git
       $ git remote add origin git@github.com:michaelliao/learngit.git
```
- origin是默认表示远程仓库的意思
- 地址是ssh地址

第一次要用$ git push -u origin master
- 之后就用 git push origin就可以
这样就关联好了

2.增（上传文件的步骤）

2.1首先要增加文件到git暂存区中

上传文件格式：$ git add .表示把该文件夹下的所有文件都添加到暂存区

如果修改了多个文件，并且想将这些更改一起推送到GitHub上

git add .
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

    该命令会将所有已修改的文件添加到Git索引中，包括新添加的文件和被修改的文件。


#### 2.2其次要上传文件到远程仓库

* $ git commit --m"输入备注"

#### 2.3最后要传输到GitHub中

* $ git push origin master

### 3.删（删除文件的步骤）

* git rm -r 文件夹名称（或文件）
  * git commit -m "删除文件夹"
    * git push origin 分支名

### 4. 将本地分支推送远程仓库

* ```
  git push -u origin 分支名

-u是upstream，表示的是将这个分支设置为上游分支
- 下一次直接git push就会推送到这个分支上

git pull

使用场景

拉取远程仓库的更改：如果您的团队使用Git进行协作开发，其他团队成员可能会推送更改到远程仓库中。在这种情况下，您可以使用git pull命令将这些更改拉取到本地仓库中，以便您可以查看并处理这些更改。

git pull <远程仓库名> <远程分支名>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20


## git clone

* 从远程库克隆

	`$ git clone SSH地址`

## git 分支

### 创建于合并

#### 不保留分支信息

* 在一个主分支下，你创建了一个分支，在分支上的任何操作都不会影响到主分支。这样大大方便了多人协同操作

* 命令

  1. 创建并切换到新的`dev`分支，可以使用：


 $ git switch -c dev
 1
2
3

* 如果仅仅是切换分支，可以使用：


   $ git switch 分支名
   1
2
3
4
5
6
7

     

2. 之后我们可以正常的add， commit

3. 合并指定分支到当前分支，可以使用：


 $ git merge dev
 1
2
3

4. 删除分支，可以使用


 $ git branch -d dev
 1
2
3
4
5
6
7
8
9

#### 保留分支信息

* 前头照旧.

* 合并分支时

  * ```
    $ git merge --no-ff -m "merge with no-ff" dev


* `no-ff`参数是指：no fast forward（不要快速合并）

修改旧的分支名字

使用下面的命令将分支重命名为新的名称。

git branch -m <旧分支名> <新分支名>
1
2
3
4
5
6
7
8
9

### 解决冲突

* 解决冲突前

  ![git笔记1](/images/git使用心得/git笔记1.png)

* 假设您正在合并两个分支`branchA`和`branchB`，并且这两个分支都对同一个文件的同一行进行了修改。在合并时，Git会将冲突内容标记出来，具体如下所示：


<<<<<<< branchA
这是分支A对该文件的修改
=======
这是分支B对该文件的修改
>>>>>>> branchB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

  * 其中，`<<<<<<< branchA`表示以下的内容是分支A对该文件的修改
  * `=======`表示分隔符号，表示分支A和分支B的内容分隔开来
  * `>>>>>>> branchB`表示以下的内容是分支B对该文件的修改

* 解决冲突后

  ![git笔2记](/images/git使用心得/git笔2记.png)

* ### bug分支

* 基本逻辑：通过创造临时分支 —> 修复bug —> 合并分支 —> 删除分支

  * 情景再现：你手头有任务未完成，要保存工作现场，再去修复bug

    * 修复前：

      * Git提供了一个`stash`功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：


    $ git stash
    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

  * 这时候的工作区是干净的

* 开始修复：

  * 确定bug分支，假设是master
  * 创建master的修复bug分支 `issue-01`
  * 修改——add——commit
  * 切换回master分支，并删除`issue-01`分支

* 修复后：

  * 复原原先的工作区：

    * 回到自己的工作分支

    * `git stash list` 查看保存的工作现场的地址

      * ```
        stash@{0}: WIP on dev: f52c633 add merge


      * 如果有多个stash历史，就要附上参数：`git stash apply stash@{0} `

    * `git stash pop`这条指令相当于恢复工作区并删除，等同于底下两条命令

      * `git stash apply`
      * `git stash drop`

dev分支是从master分支分出来的，所以bug在dev分支上也存在

在之前commit时有编号4c805e2

$ git commit -m "fix bug 101"
[issue-101 4c805e2] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)
1
2
3
4
5

* 利用`cherry-pick`命令，把一个特定的提交到当前分支

  * ```
    $ git cherry-pick 4c805e2

之后也会得到一个commit编号，虽然改动相同，但是操作是不一样的

git 协同

Fork 项目：如果你想为某个开源项目做出贡献，可以先 fork 该项目的代码仓库到你的 GitHub 账户下，然后将代码 clone 到本地计算机中进行开发。
1. 如在本地仓库中创建并切换到dev分支，使用以下命令：
  1
  $ git switch -c dev origin/dev
  - 该命令会在本地创建并切换到名为dev的新分支，
  - 并将该分支设置为追踪远程仓库中的dev分支（origin/dev）
  - 这样，其他人就可以在本地仓库中进行dev分支上的开发，并将修改推送到远程仓库中的dev分支上。
2. 修改代码
3. 用git diff命令看看做了哪些操作（强烈建议在推送前看看）
4. git add 上传更新后的代码至暂存区
5. git commit 可以将暂存区里更新后的代码更新到本地git
6. git push origin xxx 将本地的xxxgit分支上传至github上的git
（如果在写自己的代码过程中发现远端GitHub上代码出现改变）
1. git checkout main 切换回main分支
2. git pull origin master(main) 将远端修改过的代码再更新到本地
3. git switch xxx 回到xxx分支
4. git rebase main 我在xxx分支上，先把main移过来，然后根据我的commit来修改成新的内容
  （中途可能会出现，rebase conflict —–》手动选择保留哪段代码）
5. git push -f origin xxx 把rebase后并且更新过的代码再push到远端github上（-f —》强行）
6. 原项目主人采用pull request 中的 squash and merge 合并所有不同的commit
  
  (远端完成更新后)
7. git branch -d xxx 删除本地的git分支
8. git pull origin master 再把远端的最新代码拉至本地
创建 Pull Request：
- 当你完成了代码修改并将它们推送到远程仓库中的分支上后，可以在 GitHub 上创建一个 Pull Request 请求，请求将你的修改合并到原始仓库中。
- 在创建 Pull Request 时，你可以描述你所做的修改以及为什么认为它们应该被合并到原始仓库中。原始项目的维护者可以查看你的 Pull Request 请求，并决定是否接受你的修改。
Code Review：
- 在你的 Pull Request 请求被接受之前，可能需要进行代码审查，以确保你的代码符合项目的代码规范和质量标准。
- 接受合并请求：如果你的 Pull Request 请求被接受并合并到原始仓库中，那么你的修改就会成为该项目的一部分。

git 标签

增

在Git中打标签非常简单，首先，切换到需要打标签的分支上：

$ git tag v1.0
1
2
3

* 如果要打以前的标签，找到历史提交的commit id，然后打上


  $ git tag v0.9 f52c633
  1
2
3
4
5
6
7

### 删

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

  * ```
    $ git tag -d v0.1

git 自定义

忽略特殊文件

原则
- 忽略操作系统自动生成的文件，比如缩略图等；
- 忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件；
- 忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。
格式
- .gitignore文件中的每一行都是一个要忽略的文件或目录的规则。规则的格式可以是文件名、目录名、通配符或正则表达式。
  
  下面是一些常见的规则格式：
  1. 文件名：指定要忽略的文件名。例如，要忽略名为config.ini的文件，可以在.gitignore文件中添加以下规则：
  1
  config.ini
  1. 目录名：指定要忽略的目录名。例如，要忽略名为logs的目录，可以在.gitignore文件中添加以下规则：
  1
  logs/
用add commit添加后就可以生效了

在项目开发过程中个，一般都会添加 .gitignore 文件，规则很简单，但有时会发现，规则不生效。
原因是 .gitignore 只能忽略那些原来没有被track的文件，如果某些文件已经被纳入了版本管理中，则修改.gitignore是无效的。
那么解决方法就是先把本地缓存删除（改变成未track状态），然后再提交。
1
2
3
4
5
git rm -r --cached .

git add .

git commit -m 'update .gitignore'

不该被传到仓库的文件

1. 敏感信息和凭证

API密钥、令牌：如访问外部服务的API密钥或身份验证令牌。
数据库凭证：数据库用户名和密码。
配置文件：包含敏感信息的配置文件，如.env文件中的环境变量。
私钥文件：如SSH私钥、TLS证书的私钥等。

2. 个人配置文件

IDE配置：特定于个人开发环境的IDE配置文件，如.idea/（IntelliJ IDEA）、.vscode/（Visual Studio Code）目录。
操作系统特定文件：如.DS_Store（macOS）、Thumbs.db（Windows）。

3. 依赖和构建输出

依赖目录：如node_modules/、vendor/目录，这些通常可以通过依赖管理工具在构建时自动安装。
编译输出：编译后的二进制文件、对象文件（.o、.obj）、临时文件等。
日志文件：运行时生成的日志文件。

4. 大型文件和二进制文件

大型文件：视频、图片集合、大型数据集等，这些文件可以使用Git LFS（Large File Storage）或其他文件存储服务管理。
二进制文件：除非必要，一般不推荐将二进制文件存储在Git中，因为它们不易进行差异比较，且可能迅速增加仓库大小。

防止敏感信息上传的策略

使用.gitignore文件：在.gitignore文件中列出不应跟踪的文件和目录，以防止它们被意外提交。
审查提交和合并请求：在提交或接受合并请求之前，进行代码审查以确保没有敏感信息或不应上传的文件被包含。
使用Git钩子：利用Git钩子（如pre-commit钩子）自动检查敏感信息。
使用秘密管理工具：对于需要在项目中使用的敏感信息，考虑使用秘密管理工具，如HashiCorp Vault、AWS Secrets Manager、GitHub Secrets等。

git log

git log –color –graph –pretty=format:’%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset’ –abbrev-commit

Jexi Jiang' Blog