全局设置
用户名和邮箱
git config --global user.name "xxx" //设置用户名为xxx
git config --global user.email "xxx" //设置邮箱为xxx
克隆远程仓库
git clone <仓库名> // 克隆远程分支时,只会克隆master分支,其余分支需要单独检出
初始化仓库
git init
把工作区的文件添加到暂存区
git add . // 添加所有的文件到暂存区
git add <文件名> // 添加当前文件到暂存区
把暂存区中的文件提交到本地仓库
git commit -m"初始化项目" //把所有的文件都提交到本地仓库,并带上描述信息
查看当前分支的状态
git status // 会有一些提示,根据提示可做下一步的操作
分支
检查本地分支
git branch
检查远程分支
git branch -r
检查本地和远程分支
git branch -a
创建分支,并切换
git switch -c dev //创建并切换到dev分支
// 如果已存在该分支,则报错 fatal: A branch named 'dev' already exists.
切换本地分支
git switch dev //切换到dev分支
检出远程分支
git checkout -b dev origin/dev //检出远程的dev分支到本地新创建的分支dev
删除本地分支
git branch -d dev //删除本地dev分支
git branch -D dev //强制删除本地dev分支(当分支没有被合并使用的时候)
远程分支与本地分支关联
git remote add origin <远程分支的名称>
// 如果报错 fatal: remote origin already exists.
git remote rm origin // 那么需要先删除与origin的远程库的关系
远程分支与本地分支关联
git branch --set-upstream-to <本地分支的名称> origin/<远程分支的名称>
查看提交历史
git log
q // 退出查看
HEAD介绍
我们首先看一下 “HEAD”。HEAD 是一个对当前检出记录的符号引用 —— 也就是指向你正在其基础上进行工作的提交记录。HEAD 总是指向当前分支上最近一次提交记录。大多数修改提交树的 Git 命令都是从改变 HEAD 的指向开始的。HEAD 通常情况下是指向分支名的(如 bugFix)。在你提交时,改变了 bugFix 的状态,这一变化通过 HEAD 变得可见。
撤销变更
在 Git 里撤销变更的方法很多。和提交一样,撤销变更由底层部分(暂存区的独立文件或者片段)和上层部分(变更到底是通过哪种方式被撤销的)组成。我们这个应用主要关注的是后者。
主要有两种方法用来撤销变更 —— 一是 git reset,还有就是 git revert。接下来咱们逐个进行讲解。
git reset(用于本地撤销)
git reset HEAD^
git reset HEAD~1
数据从暂存区中 变更到了工作区 代码还是存在的
git revert(用于远程撤销)
git revert HEAD //它会创建一个新的提交,为当前提交的上一个提交信息
最后提交并push远程即可
文件从暂存区回退到工作区
git restore --staged . // 所有文件都退回到工作区
git restore --staged <文件名> // 当前文件退回到工作区
文件从工作区删除
git restore . // 撤销所有文件的修改
git restore <文件名> // 撤销当前文件的修改
移动提交记录
git cherry-pick
git cherry-pick <提交号> //可以是多个提交号
如果你想将一些提交复制到当前所在的位置(HEAD)下面的话, cherry-pick 是最直接的方式了,通常用于bug分支合并到其他分支中(还需要先提交原有分支,而后解决冲突即可)
git rebase
假设一个master(C1)分支中创建了一个dev分支,进行开发,开发到一半的时候,发现线上有一个bug,于是我们就切换到了master分支下面去创建一个bug分支,进行修复bug,最后合并到的master分支(此时为C2),而后切换到dev分支,并使用git cherry-pick <提交号> 修复bug。
当我们在dev分支上把功能开发好了以后,想要把代码合并到master的时候。我们发现并没有和平常一样那么的顺利。为啥呢?因为此时dev分支不是从C2中创建出来的,而是从C1中创建出来的。master分支已经向前进了一步。此时就需要合并,解决冲突,在进行提交
然而先在dev分支上先使用 git rebase master,即拉取master上最新的分支,解决冲突,而后添加到暂存区,而后在执行,git rebase –continue(如果有冲突的话,需要执行该代码) ,push到远程此时在切换到master分支上,再进行合并分支的时候,就不会出现问题。
dev分支中:
git rebase master
//有冲突,解决---start
git add .
git rebase --continue
//有冲突,解决---end
git push origin dev
切换到master分支
git switch master
//合并dev分支到master
git merge dev
git push origin master
远程拉取
git pull // 切换到当前分支下,简写
git pull origin master --allow-unrelated-histories //拉区不下来的时候,强制合并
提交分支到远程
git push origin master // 提交master分支到远程
注意:需要先切到当前分支中
git push // 此命令也可以提交分支,当然最好还是强调一下需要提交到那个分支,一旦分支比较多的话,万一当前分支并不想提交,而你却使用了这个命令,就提交上去了,指定提交的分支,可以避免这些问题:
修改提交描述信息
git commit --amend
输入 i 进入输入模式
修改要修改的描述信息
按下ESC
输入 :wq 回车退出保存修改
储藏代码
应用场景:
在上面介绍的git rebase例子中,有一步的做法有些不合理,当我在dev分支中开发的时候,线上发现一个bug,那么需要从master分支中切出一个bug分支,在 dev分支切换到master分支的时候,此时dev分支是否需要提交?显然是不应该提交的,因为dev分支我才进行了一半,那要怎么办,我既想保留dev中的代码,又不想提交代码生成提交记录。有一个命令可以做到,即 git stash,余下流程还是按照之前的走git stash //作用:可以把当前工作现场储藏起来,此时再去查看工作树,发现它是干净的,这样你就可以愉快的解决bug了
git stash list // 查看所有储藏的代码列表记录,
git stash apply stash@{0} // 恢复想要恢复的储藏代码,一般都是列表中的第一条数据,stash@{0}可选择填写需要的记录