git使用及常用case

脱缰小野马
115 阅读5分钟

用好git, 它的模型要了解一下. 本地的几个区域和它们的特点要了解清楚. 也就是一些关键的命令的特性一定要搞清楚. 如

  • git add前提是了解stag特点,要求每次修改,挑选下需要提交的都得暂存一下
  • git branch 对分支crud
  • git merge other_branch 合并分支,要求本地仓库必须存在other_branch
  • git fetch + git merge == git pull

记得本地的暂存区是什么? 本地仓库在哪儿看.

本地的几个区域

image.png

下面这个图展示了工作区、版本库中的暂存区和版本库之间的关系： image.png

stag这个单词的含义:

  • 发布环境中的stag: "Staging"在英文中有“布置”、“准备”的意思。对于一个预发布环境而言，这个词非常贴切，因为这个环境用于将一个即将发布的版本做最后的准备和验证，就像在上台演出前的彩排一样。
  • git中的暂存区: 在版本控制系统（如Git）中，"staging area"（暂存区域或称为索引）的功能是用来暂时存储那些已经被修改但还没有提交到版本库中的文件。这允许开发人员选择性地提交部分改动，而不是一并提交所有改动。

暂存区特点:

  • 新增的文件要git add被管理(同时放到stag)
  • 已存在的文件修改了要再次git add存放到stag

case: 比如一次修改了多个文件, 可以挑选部分文件放到暂存区进行提交.

image.png

image.png

NOTE: 本地 和 远端 仓库并不是自动同步的, 比如远端新增了分支或该分支有新的提交, 本地默认是无法自动感知的.

分支操作

git branch
git branch new_branch   # 注意: 这个命令完全不会被git checkout -b所取代.
git branch -d new_branch

# 删除主机的分支可以使用 --delete 参数，以下命令表示删除 origin 主机的 master 分支：
git push origin --delete master


//查看本地分支和远端分支的映射关系
git branch -vv

NOTE: 本地分支必须关联远端分支

  1. 远端创建stag-v1分支
  2. 本地创建stag-v1分支,并修改提交
  3. 本地push, 则会提示要关联到上游哪个分支

本地仓库和远程仓库需要关联

FAQ:

  • 1.我这个仓库和github哪个仓库关联?(当然一般相同的名称)
  • 2.我这个仓库这个分支将会提交github哪个分支?
//将other_branch合入到当前branch
git merge other_branch
  • 1.本地要存在这个other_branch
  • 2.如果不存在可以设置远端的 origin/other_branch

删除分支到底删除了什么 blog.csdn.net/qq_43827595…

FAQ

    1. 如果我本地改了一些, 还没git add, 结果想pull一下最近的
    1. 如果本地commit了多次, 还没提交, 想合并为一次commit(需suqash压缩)
    1. 如果已经提交到了远端, 但是后悔了, 想删除远端的这次commit
    git reset --hard HEAD^
git push origin master -f
    1. 我这个分支想同步(merge)一下远端的另一个分支的代码, 然后继续修改,既想保持最新的更新, 又想来继续更新.
    1. dev分支我本地仓库提交了多次, 但是远端的dev分支已经有其他人提交了(无冲突), 会发生什么? 我本次push会报错
Push of the current branch "stag-v3" was rejected.
Remote changes need to be merged before pushing.

解决: 如果本地有提交

git fetch origin
git merge origin/stag-v3 

// 以下命令将本地的 master 分支推送到 origin 主机的 master 分支。
git push origin master

// 如果本地版本与远程版本有差异，但又要强制推送可以使用 --force 参数：
git push --force origin master

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

如果本地无提交

git pull

所以你看, 上面两种方式也不是完全等价, 不同的case还得祭出不同的命令来解决.

refs

在Git中，refs（References的缩写）是指向特定提交对象（commits）的指针或标识符。它们用来定义仓库中的命名空间，用于管理分支、标签和远程仓库等元素。

常见的refs位置包括：

分支（Branches）：

  • 本地分支：储存在 .git/refs/heads/ 目录下。例如，有一个名为 main 的分支，其refs路径将是 .git/refs/heads/main。
  • 远程分支：储存在 .git/refs/remotes/ 下。例如，远程仓库 origin 的主分支，其refs路径为 .git/refs/remotes/origin/main。
  • 标签（Tags）： 储存在 .git/refs/tags/ 目录下。例如，一个名为 v1.0 的标签，其refs路径将是 .git/refs/tags/v1.0。
  • 其他特殊引用： 例如 HEAD，指向当前所检出的分支或具体的提交。

HEAD

HEAD指的是当前活跃分支的游标 HEAD 在Git中是一个引用（reference），它指向当前工作目录中的最新提交。

.git/refs/heads
├── master
├── stag
├── stag-v1
└── stag-v4

detached HEAD

Git 中正常的流程应该是 HEAD 指向某个分支，分支又有对应的 commitId，

可以尝试玩一玩这个游戏, 理解分离的head git-school

当你在进行checkout时提供了一个commit而不是分支名称，你就进入了一种“特殊”的状态里 —— detached HEAD。

git reflog

git reflog 是本地的功能，它记录的是你在本地仓库中进行各种操作（比如提交、重置、检出等）所引起的引用变化。换句话说，git reflog 记录的只是你自己在该仓库上的本地操作历史，它不会记录其他人在他们各自本地仓库中进行的操作。

私有的log: git reflog

共有的log: git log

avatar
文章
阅读
粉丝