git使用心得

19 min

git init

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

git status

  • 我们随时掌握工作区的情况,就要用到$ git status这个命令

    • 工作区,暂存区,版本库和远程仓库

      • 修改的文件是在工作区
      • 我们要用add把它放到暂存区
      • 通过commit推到版本库
      • 最后通过push推送到远程仓库去
    • 版本回退

      • 如果想要丢弃工作区的修改

        $ 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^

          命令表示返回到上一个版本

git push

1.本地和远程仓库的关联

  1. $ git remote add origin git@github.com:michaelliao/learngit.git
    • origin是默认表示远程仓库的意思
    • 地址是ssh地址
  2. 第一次要用$ git push -u origin master

    • 之后就用 git push origin就可以

    这样就关联好了

  3. 查看远程仓库地址

    git remote -v

2.增(上传文件的步骤)

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

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

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

    • git add .

      该命令会将所有已修改的文件添加到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

将 Fork仓库与原始仓库同步

  • 添加原仓库为远程源(upstream)。
  • 使用 git fetch upstream 拉取原仓库的最新更改。
  • 使用 git mergegit rebase 将这些更改合并到你的本地分支。
  • 推送更新到你的 Fork 仓库。

git 回溯

  • 如何回到过去的版本

    git checkout — <文件名> 表示将版本库里的版本替换工作区的

      • git checkout <commit-hash>
      • git checkout main

git 版本控制

  • 丢弃文件修改
    • git status
  • 从暂存区回退
    • git status
  • 从版本库回退
    • git reset -- hard HEAD^
    • git reset -- hard HEAD^^
    • git reset -- hard HEAD~100

git clone

  • 从远程库克隆

$ git clone SSH地址

git 分支

创建于合并

不保留分支信息

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

  • 命令

    1. 创建并切换到新的dev分支,可以使用:

      $ git switch -c dev
      • 如果仅仅是切换分支,可以使用:

        $ git switch 分支名
        • 注意 :heavy_exclamation_mark:在你切换分支之前,你需要先提交你当前分支上的所有修改。这样,当你切换到另一个分支时,你在当前分支上的修改就不会被带到新的分支上。
    2. 之后我们可以正常的add, commit

    3. 合并指定分支到当前分支,可以使用:

      $ git merge dev
    4. 删除分支,可以使用

      $ git branch -d dev

保留分支信息

  • 前头照旧.

  • 合并分支时

    • $ git merge --no-ff -m "merge with no-ff" dev
      • no-ff参数是指:no fast forward(不要快速合并)

修改旧的分支名字

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

    • git branch -m <旧分支名> <新分支名>

解决冲突

  • 解决冲突前

    git笔记1

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

    <<<<<<< branchA
    这是分支A对该文件的修改
    =======
    这是分支B对该文件的修改
    >>>>>>> branchB
    • 其中,<<<<<<< branchA表示以下的内容是分支A对该文件的修改
    • =======表示分隔符号,表示分支A和分支B的内容分隔开来
    • >>>>>>> branchB表示以下的内容是分支B对该文件的修改
  • 解决冲突后

    git笔2记

  • bug分支

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

    • 情景再现:你手头有任务未完成,要保存工作现场,再去修复bug

      • 修复前:

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

          $ git stash
        • 这时候的工作区是干净的

      • 开始修复:

        • 确定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(-)
    • 利用cherry-pick命令,把一个特定的提交到当前分支

      • $ git cherry-pick 4c805e2
      • 之后也会得到一个commit编号,虽然改动相同,但是操作是不一样的

git 协同

  • Fork 项目:如果你想为某个开源项目做出贡献,可以先 fork 该项目的代码仓库到你的 GitHub 账户下,然后将代码 clone 到本地计算机中进行开发。

    1. 如在本地仓库中创建并切换到dev分支,使用以下命令:

      $ git switch -c dev origin/dev
      • 该命令会在本地创建并切换到名为dev的新分支,

      • 并将该分支设置为追踪远程仓库中的dev分支(origin/dev

      • 这样,其他人就可以在本地仓库中进行dev分支上的开发,并将修改推送到远程仓库中的dev分支上。

    2. 修改代码

    3. git diff命令看看做了哪些操作(强烈建议在推送前看看)

      • 查看本地main分支和远程仓库main分支区别
        • git diff main origin/main
    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
    • 如果要打以前的标签,找到历史提交的commit id,然后打上

      $ git tag v0.9 f52c633
    • 如果要加备注

      $ git tag -a <tag_name> <commit_hash> -m "Tag message"
      • git tag v3.0 -m"第三版-将修改词表接口逻辑,增加web端用户实时查看成员录音信息功能"
      • git tag -a v1.0.0
  • 查看tag备注 git tag -a benchmark

    • git show v1.0

  • 标签打错了,也可以删除:

    • $ git tag -d v0.1

  • 将本地tag推送到仓库

    • git push origin --tags

git 自定义

忽略特殊文件

  • 原则

    • 忽略操作系统自动生成的文件,比如缩略图等;
    • 忽略编译生成的中间文件、可执行文件等,也就是如果一个文件是通过另一个文件自动生成的,那自动生成的文件就没必要放进版本库,比如Java编译产生的.class文件;
    • 忽略你自己的带有敏感信息的配置文件,比如存放口令的配置文件。
  • 格式

    • .gitignore文件中的每一行都是一个要忽略的文件或目录的规则。规则的格式可以是文件名、目录名、通配符或正则表达式。

      下面是一些常见的规则格式:

      1. 文件名:指定要忽略的文件名。例如,要忽略名为config.ini的文 件,可以在.gitignore文件中添加以下规则:
      config.ini
      1. 目录名:指定要忽略的目录名。例如,要忽略名为logs的目录,可以在.gitignore文件中添加以下规则:
      logs/
  • add commit添加后就可以生效了

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

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

清除指定文件记录

删除远程仓库commit有关记录

有时会误操作把不应该的文件commit到本地仓库,push后就会有记录,后续就算在之后的commit版本删除该文件,但还是可以被回滚导致机密文件泄露

# 1. 创建仓库的全新克隆
git clone --mirror 你的仓库地址 新建文件的名字
cd new-repo(新建文件的名字)

# 2. 使用 git filter-repo 删除机密文件
git filter-repo --path '相对于.git文件的相对地址' --invert-paths

# 3. 强制推送修改到远程仓库
git push --mirror

# 4. 通知团队成员重新克隆仓库
  • 检查是否删除干净

    • ·git log --all --pretty=format:%H -- be/.env(最后是文件相对路径)

      查看commit中还有没有敏感文件的记录

    • :expressionless:以后忽略 .env 文件 最好还是用*.env

重置本地仓库

  • git status --ignored -s | grep '!!'
    • 查看哪些文件成功被ignore
  • 我是直接用
    • git filter-repo --path '相对于.git文件的相对地址' --invert-paths --force

总结

git-cheat-sheet (gitee.io)

拓展学习

commit 信息编写

用于规范化历次提交内容改动类型,同时也是提醒自己每个 commit 要认真对待,干净的 commit 有利于大家交流 — Li

  1. build:主要目的是修改项目构建系统(例如 glup,webpack,rollup 的配置等)的提交
  2. ci:主要目的是修改项目继续集成流程(例如 Travis,Jenkins,GitLab CI,Circle等)的提交
  3. docs:文档更新
  4. feat:新增功能
  5. fix:bug 修复
  6. perf:性能优化
  7. refactor:重构代码(既没有新增功能,也没有修复 bug)
  8. style:不影响程序逻辑的代码修改(修改空白字符,补全缺失的分号等)
  9. test:新增测试用例或是更新现有测试
  10. revert:回滚某个更早之前的提交
  11. chore:不属于以上类型的其他类型