1676540161,

配置步骤

创建仓库

创建目录，比如 mydemo，表示项目的根目录，

mkdir mydemo

进入目录，

cd mydemo

初始化git仓库，

git init

此时在mydemo目录下会多出一个 .git 目录，用于管理。

提交

新建一个文件，

touch readme.txt

将文件添加到暂存区，

git add readme.txt

将暂存区的文件修改提交到本地仓库，

git commit -m "<commit for this commit>"

使用如下命令查看当前工作区的readme.txt是否有新的修改，

git status readme.txt

假设修改readme.txt文件后，想查看修改内容，使用如下命令，

git diff readme.txt

然后再次将修改添加到暂存区，然后再提交修改到本地仓库，

git add readme.txt

git commit -m "<comment for this commit"

查看日志

已经对readme.txt提交两次了，查看此文件的提交日志，

git log readme.txt

则按提交时间倒序显示日志，其中一长串的hash值就是版本号。

每次提交日志显示在一行中，执行如下命令，

git log --pretty=oneline readme.txt

回退

假设本次提交后，想回退到上一个（本次提交前的）版本，

git reset --hard HEAD^

如果想回退到上上个版本，

git reset --hard HEAD^^

以此类推。但是如果回退到很多次提交之前的版本，这种方法显然不方便，假设readme.txt要回退到前100个（100次提交之前的）版本，

git reset --hard HEAD~100

此时如果再使用

git log readme.txt

查看文件提交日志，则不再显示那些被回退的提交日志。

回退后，如要回到回退前的某个版本，

git reset --hard <version number>

由于回退后，git log可能不再显示回退前的版本号，所以如果不知道版本号，则使用如下命令，

git reflog readme.txt

查看readme.txt文件的日志。

根据选项值不同，git reset 有三种模式，上面所说的是第一种即hard模式，回退后，工作区和暂存区都是干净的，被回退的提交内容丢失。

第二种模式，回退上一次提交，

git reset --soft HEAD^

此时工作区是干净的，上一次提交的内容从本地仓库撤回到暂存区。

第三种模式，即默认模式，

git reset HEAD^

此时上一次提交的内容撤回到工作区，暂存区是干净的。但是如果暂存区本来就有内容，则默认回退后，暂存区不一定是干净的。

以上回退命令可以在最后加文件名，表示对这一个文件进行回退。

git命令中，命令和选项总是在文件名（操作对象）前面，如未提供文件名参数，则默认对项目根目录下所有文件进行操作。git中可以提供一个.gitignore文件，其中包含了让git忽略的目录和文件，这种情况下，git不再管理被忽略的目录和文件，所以git命令也不作用于那些目录和文件上。当然，文件名参数也可以是目录，表示对指定目录下的文件（包含子目录下的文件）执行对应的git命令，比如’.’表示当前目录，’..’表示上一层目录。

撤销

假设工作区内容作了修改，现在需要丢弃所有修改，分以下两种情况讨论：

未执行 git add . ，那么使用 git checkout -- <文件路径> 撤销本次工作区的修改，注意 两个短横线，否则变成切换分支。 已执行 git add . ，那么， 先使用 git reset HEAD -- <文件路径> 将暂存区内容撤回到工作区，此时变成情况 1 ，按情况 1 执行。

如果 git add .之后，又对工作区作了修改，此时若想全部撤销修改，那么先执行情况 1，然后再执行情况 2，

git checkout -- * 是撤销从上次提交（commit）之后所做的所有修改

git checkout -- filaname 是撤销从上次提交（commit）之后的单个文件的修改

假设现在再次修改readme.txt文件的内容，修改后发现这些修改内容需要丢弃，当然直接在文件中手动改回去也可以，但有时候文件比较大，修改内容比较多，就不容易直接改回去了，需要执行git撤销命令撤销工作区的修改，

git checkout -- readme.txt

撤销工作区中readme.txt文件的修改，此时，如果暂存区有readme.txt的修改，则这个修改不会被撤销。

如果想撤销暂存区的修改到工作区中，那么使用如下命令回退到当前（最后一次提交后）版本，也就是，不回退本地版本库到上一次版本，进撤回暂存区内容到工作区，

git reset HEAD

HEAD表示当前版本，HEAD^表示上一个版本

删除文件

直接在工作区删除相应文件即可，git会自动跟踪信息。删除后，如果想在版本库中彻底删除，则继续使用命令，

git rm <filename to be deleted>

git commit -m "delete <filename>"

其中，rm 命令也可以写成add

如果在工作区删除文件后发现是误删，需要撤销操作，执行

git checkout -- <filename>

远程仓库

在github上创建一个仓库（仓库名最好与本地仓库名一致），然后在本地mydemo下执行，

git remote add origin https://github.com/gaoshoufenmu/mydemo.git

把本地仓库内容推送到远程，

git push origin master

创建分支

创建dev分支，然后切换到dev分支上，

git checkout -b dev

表示创建并切换，相当于，

git branch dev

git checkout dev

查看所有分支，

git branch

当前分支前面有一个星号标识。

在dev分支上的修改提交不会影响到master分支上。

假设要把dev分支的修改合并入master分支，首先切换到master分支，

git checkout master

然后进行合并，

git merge dev

假设分支使用完毕，需要删除，使用

git branch -d dev

冲突

假设将dev分支修改内容合并入master分支时产出冲突，则使用

git status

查看冲突状态，即，哪些文件冲突了，

然后打开这些冲突文件，git 使用 <<<<<<<<<<<, ==============, >>>>>>>>>> 标记出不同分支内容，其中<<<<<<<< HEAD表示主分支修改内容，>>>>>>>>> dev 指dev分支修改内容，于是手动修改文件内容为自己想要的，然后再add到暂存区并commit到本地仓库。

使用上面的合并分支命令，在删除dev分支后，会丢掉分支信息，所以可以添加参数如下，

git merge --no-ff -m "<merge commit>" dev

这样，删除dev分支后，依然可以通过git log 查看被删除的分支版本号

git stash 使用

开发到一半的时候，需要同步远端代码，

git stash

git pull

git stash pop

然后继续本地开发。

工作流被打断，比如线上bug，

git stash // 保存开发了一半的代码

/* 修改代码解决bug */

git add .

git commit -m "fix a bug"

git stash pop

但是一般并不在用于发布代码的master分支上直接修改。所以实际情况，假如在dev上开发新代码，此时如果线上代码遇到bug，

git checkout master // 切换到master

git checkout -b bug_b // 创建一个分支用于解决bug

/* 解决bug */

git add .

git commit -m “fix a bug”

git checkout master

git merge --no-ff -m "merge bug branch" bug_b

git branch -d bug_b // 删除bug临时分支

git checkout dev // 回到开发分支

这样看来，实际上并不需要在dev将开发代码stash起来。

查看stash内容

git stash list

恢复stash的内容，

git stash apply

这种恢复不会删除stash内容，需要使用

git stash drop

来删除stash。当然可以直接使用

git stash pop

实现恢复然后删除。

查看分支

git branch -a

查看本地分支和远端分支（在本地的镜像）。

查看提交记录

git log 查看本地提交记录

git log remotes/origin/master 查看远端提交记录（注意不是实时的远端提交记录，而是本地上次拉取远端代码后的一个历史快照）

如果只看提交id和提交说明，可以用 git log --oneline

查看实时远端提交记录，先获取远端数据 git fetch origin master，然后在查看 git log remotes/origin/master， 此时新获取的代码只存在于本地 git 仓库，还不在本地工作区，因为仅仅 fetch，未 merge。如果此时想创建一个 branch 来跟踪远端实时代码，

git checkout -b new-branch b2b6ec7

创建新分支 new-branch，并指定从远端的提交记录id b2b6ec7，这意味着new-branch只跟踪到远端提交记录b2b6ec7为止（包括了远端更早的提交，但不包括比b2b6ec7更新的提交），如果不指定远端提交记录b2b6ec7，那么就是创建分支并直接跟踪到远端实时（命令执行当前）最新的提交。

子模块更新

在使用 git pull origin master 更新项目后，项目中的子模块（submodule）并不会得到更新，此时如想更新子模块，还需要执行

git submodule sync git submodule update --init --recursive

删除某个子模块

删除子模块目录及源码

rm -rf 子模块目录

删除.gitmodules中的对应子模块内容

vi .gitmodules

删除.git/config配置中的对应子模块内容

vi .git/config

删除.git/modules/下对应子模块目录

rm -rf .git/modules/子模块目录

删除git索引中的对应子模块

git rm --cached 子模块目录

CRM论坛（CRMbbs.com）——一个让用户更懂CRM的垂直性行业内容平台,CRM论坛致力于互联网、客户管理、销售管理、SCRM私域流量内容输出5年。 如果您有好的内容，欢迎向我们投稿，共建CRM多元化生态体系，创建CRM客户管理一体化生态解决方案。本文来源：知了社区基于知识共享署名-相同方式共享3.0中国大陆许可协议,git 常用操作