git的学习和使用

仅供学习使用

关于git入门

git入门教程-廖雪峰

关于git系统阐述

推荐书籍《git权威指南》

git命令常用

git clone

从远程仓库克隆代码到本地

git clone https://gitee.com/sogou/workflow.git

分支操作branch和checkout

git branch

git branch # 查看本地分支
git branch -r # 显示远端分支
git branch -a # 查看本地及远程所有分支
git branch branch_name # 新建本地分支branch_name
git branch -D branch_name # 删除本地分支branch_name

git checkout

git checkout branch_name # 切换到本地分支name
git checkout -b CI_2/upa_dev # 新建本地分支CI_2/upa_dev，并切换到该分支
git checkout -b local_branch_name origin/master # 新建本地分支local_branch_name，并跟踪远程分支origin/master

代码提交和更新

git add

git add file_name ## 增加文件到暂存区
git add -u ## 强制增加所有add状态文件到暂存区
git add .  ## 添加所有文件到暂存区

git commit

git commit -a ## 跳过暂存
git commit --amend ## 当前提交不添加注释（修改上一个提交）
git commit -m  ## 输入提交信息

git push

把本地仓库的更改，推送到远程分支

git pull

从远程仓库拉取最新的更改到本地分支

合并冲突

在进行更新操作时，本地和远程如果同时同一个文件的同一行进行了修改，就会发生冲突，
git pull 报如下冲突错误

进行如下操作

# 修改冲突文件file.c
git add file.c
git rebase --continue

版本操作

git reset

--hard : 回退版本库，暂存区，工作区。（本地回退，本地不保留已修改的信息，需要谨慎使用）
删除工作空间改动代码，撤销 commit，撤销 git add . 

--mixed : 回退版本库，暂存区。(--mixed为git reset的默认参数，即当任何参数都不加的时候的参数)
意思是：不删除工作空间改动代码，撤销commit，并且撤销 git add . 操作
这个为默认参数, git reset --mixed HEAD^ 和 git reset HEAD^ 效果是一样的。

--soft : 回退版本库。不删除工作空间改动代码，撤销commit，不撤销git add 。

get reset HEAD^ # 本地回退，本地保留已修改的信息
git reset --hard HEAD^  #回退到上个版本
git reset --hard HEAD~3  #回退到前3次提交之前，以此类推，回退到n次提交之前
git reset --hard commit_id  #退到/进到 指定commit的sha码
git reset --soft HEAD^ #仅仅是撤回commit操作，本地修改或者新增的代码仍然保留。就是说本地代码没有变动

git stash

将本地没提交的内容(git commit的内容不会被缓存 但git add的内容会被缓存)进行缓存并从当前分支移除，缓存的数据结构为堆栈，先进后出.

stash只会缓存被git追踪的文件

用法：git stash list [<选项>]
  或：git stash show [<选项>] [<stash>]
  或：git stash drop [-q|--quiet] [<stash>]
  或：git stash ( pop | apply ) [--index] [-q|--quiet] [<stash>]
  或：git stash branch <分支名> [<stash>]
  或：git stash clear
  或：git stash [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
          [-u|--include-untracked] [-a|--all] [-m|--message <消息>]
          [--pathspec-from-file=<file> [--pathspec-file-nul]]
          [--] [<路径规格>...]]
  或：git stash save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
          [-u|--include-untracked] [-a|--all] [<消息>]

git stash # 将当前工作区未push的更改暂存，回退到上一版本，
git stash save 
git stash save "标记缓存内容" #作⽤等同于git stash，区别是可以加⼀些注释， 执⾏存储时，添加注释，⽅便查找
git stash list # 返回缓存的列表
git stash pop # 将堆栈中最新的内容pop出来应用到当前分支上，且会删除堆中的记录, 如果pop出来的内容有冲突，git会中断此次pop并告知你需要进行冲突解决
git stash apply 讲上一次暂存的更改，恢复。与pop相似，但他不会在堆栈中删除这条缓存，适合在多个分支中进行缓存应用
git stash drop [名] # 删除单个缓存 举例git stash drop stash@{0}
git stash clear # 全清
git stash show [名] #显示与当前分支差异 举例git stash show stash@{0} 加上-p可以看详细差异

其它

git log

显示日志/历史提交信息

git log --online // 显示简要信息
git log --graph // 画出树状图
git log -p
git log -<n>  // 显示日志个数限制
git log -2 // 显示最近的2个提交log

git diff

比较文件的更新差异

git status

查看当前workspace的文件状态

git别名的配置

vim ~/.gitconfig

插入如下配置

[alias]

    st = status
    br = branch
    cm = commit
    rb = rebase
    co = checkout
    rt = reset

部分命令详解

git cherry-pick

参考链接
git fetch 命令用于从远程获取代码库。
git cherry-pick 命令的作用，就是将指定的提交（commit）应用于其他分支。

git fetch https://gitee.com/dromara/go-view.git refs/changes/81/13514181/1
git cherry-pick FETCH_HEAD

git fetch和git pull的区别

git fetch命令从远端仓库中下载commits, files, refs到本地仓库中。当你想要看看其他人都在做些什么的时候，就要使用fetch命令。这跟svn update命令很像，同样可以让你看到远端仓库的所有提交进展，但是fetch命令并不强迫让远端的变更合并到你的仓库。Git会对本地内容与fetch下载的内容进行隔离；这就保证了fetch命令更新的远端变更不会对本地正在进行的开发工作产生任何影响。如果想查看通过fetch命令下载的内容，需要显式地通过git checkout命令检出你希望查看的版本。因此在你还不想让远端仓库的版本合并到本地之前，但仍然希望可以查看一下远端版本都做了哪些变更的时候，fetch命令就是一种安全的解决方案。

git pull 和 git fetch 这两个命令都可以用于下载远端仓库。你可以认为git fetch是这两者中更加安全的那个，即便下载了远端的内容，但也不会更新你本地仓库的版本状态，以保证你本地当前代码完好无损。反观git pull命令则是一个更加激进的命令，它会下载当前正在工作的分支对应的远端内容，并且在下载成功之后马上执行一个git merge命令，为新下载下来的远端内容创建一次merge commit。此时如果你有正在进行中的工作还没准备好进行合并，这些行为可能会造成代码冲突，然后马上进入合并代码过程中解决冲突的流程。

git rebase详解

参考链接：

feature：待变基分支、当前分支
master：基分支、目标分支

这两条命令等价于git rebase master feature

git checkout feature
git rebase master

通俗的讲：rebase，变基，可以直接理解为改变基底。feature分支是基于master分支的B拉出来的分支，feature的基底是B。而master在B之后有新的提交，就相当于此时要用master上新的提交来作为feature分支的新基底。实际操作为把B之后feature的提交先暂存下来，然后删掉原来这些提交，再找到master的最新提交位置，把存下来的提交再接上去（接上去是逐个和新基底处理冲突的过程），如此feature分支的基底就相当于变成了M而不是原来的B了。（注意，如果master上在B以后没有新提交，那么就还是用原来的B作为基，rebase操作相当于无效，此时和git merge就基本没区别了，差异只在于git merge会多一条记录Merge操作的提交记录）