Git操作指南

全局配置与帮助

git config --global user.name "your name"
git config --global user.email "email@gmai.com" --global表示机器上所有Git仓库都使用该配置
git config --global credential.helper store 本地保存账号密码

版本库管理

创建版本库

步骤1:本地创建版本库目录
步骤2: 使用git init将目录变成git可以管理的仓库，生成.git目录

添加文件

步骤1: git add file 把文件添加到仓库
步骤2: git commit -m "comment" 把文件提交到仓库

查看状态

git status 显示仓库当前状态
git diff file 显示指定文件差异
git show commitId 显示某次提交的修改内容
git show <commit-hashId> filename 显示某次提交某个文件的修改信息
git log 显示提交日志记录
git log --pretty=online --graph --color
git reflog 查看命令历史，以便确认回到未来哪个版本

版本回退

git reset --hard commit_id HEAD指向当前版本；HEAD^上个版本；上100个版本 HEAD~100

管理修改

git自动创建称为stage的暂存区
git add实际上是把文件修改添加到暂存区
git commit实际上是把暂存区的所有内容提交到当前分支
git管理的是修改，而不是文件，每次修改如果不add到暂存区，就不会加入到commit中

撤销修改

git checkout -- file丢弃工作区修改，--必须存在，否则表示切换分支
添加到了暂存区时但未提交，想丢弃修改
步骤1：git reset HEAD file 暂存区修改撤销，重新放回工作区
步骤2：git checkout -- file 丢弃工作区修改

删除文件

git rm file
git checkout -- file 恢复误删

分支管理

创建分支

git branch -a 查看当前分支
git branch branchname 创建分支
git checkout branchname 切换分支
git checkout -b branchname 创建分支同时切换到创建分支
git checkout -b branchname master 从指定的master分支创建分支并切换到branchname分支
git branch -d branchname 删除分支
git branch -m master altername 将master分支名称修改为altername

合并分支

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

git merge --no-ff -m "merge with no-ff" dev 将dev分支合入当前分支，其中-m表示commit描述

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了

多人协作

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

git remote -v 查看远程库信息
git push origin branch-name 推送本地分支，如果推送失败，先用git pull抓取远程新的提交
git checkout -b branch-name origin/branch-name 在本地创建和远程分支对应的分支，本地和远程分支的名称最好一致
git checkout -t origin/branch-name 默认会在本地建立一个和远程分支名字一样的分支
git branch --set-upstream branch-name origin/branch-name 建立本地分支和远程分支的关联
git pull 从远程抓取分支，如果有冲突，要先处理冲突

多次commit合并为一次commit

有的时候我们提交了多次commit，但是这些历史记录我们没有必要都要放到远程服务器上，在推送到远端时，需要在合并的时候先合并一下

1
2
3
4
5
6
7
首先我们在master分支上创建一个新分支，叫dev：
git checkout -b dev
然后我们在dev分支上提交三次更新，分别取名为first commit 、second commit、third commit。
将多次提交合并为一次：
git merge dev --squash
一定要注意，git merge后一定要commit一下
git commit -m "update README.md"

在同一分支中使用git rebase -i HEAD~3的交互模式将多次的提交合并成一次提交。
具体的git rebase -i详细介绍：Doing git rebase –interactive, including merge conflicts

拣选合并

有时候分支之间只需要合并一个提交，而不需要合并一条分支上的全部改动。

1
2
git cherry-pick commitId #合并指定commitId到当前分支
git cherry-pick -n commitId #拣选多个提交

合并远程最新代码

在多人协同开发中，我们经常会遇到这样的问题：A在本地开发完成后，将代码推送到远程，这时候B的本地代码的版本就低于远程代码的版本，这时候B该如何从远程拉取最新的代码，并与自己的本地代码合并呢？
具体步骤如下：

1
2
3
4
5
6
7
8
从远程origin仓库获取master分支最新版本代码到本地的tmp分支
git fetch origin master:tmp
查看tmp分支与本地分支的差异
git diff tmp
将tmp分支与本地分支合并，B的本地代码已经和远程仓库处于同一个版本了
git merge tmp
最后，可以删除tmp分支
git branch -d tmp

多人协作开发模式

当从远程库clone时，默认情况下，只能看到本地的master分支。现在，要在dev分支上开发，就必须创建远程origin的dev分支到本地，创建本地dev分支:

1
git checkout -b dev origin/dev

在dev上继续修改，然后，时不时地把dev分支push到远程：

1
2
git commit -m "fix bug"
git push origin dev

如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并
如果合并有冲突，则解决冲突，并在本地提交
没有冲突或者解决掉冲突后，再用git push origin branch-name推送至远端

rebase 模式 pull

多人基于同一个远程分支开发的时候，如果想要顺利 push 又不自动生成 merge commit，建议在每次提交都按照如下顺序操作：

1
2
3
4
git stash
git pull --rebase
git push
git stash pop

更多的关于 rebase 模式 pull 细节参见：git pull –rebase的正确使用

更新所有分支

1
2
3
git pull --all
for branch in `git branch -a | grep remotes | grep -v HEAD`; do git checkout -f -t -B ${branch##remotes/origin/} $branch; done;
git checkout master

标签管理

发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。

创建标签

git tag 查看所有标签
git tag -a tagname -m "tag comment" 用于新建一个标签，默认为HEAD
git tag -a tagname -m "tag comment" commit-id 对指定的commitId创建标签

推送标签

git push origin tagname 推送本地一个标签
git push origin --tags 推送本地全部未推送的标签

删除标签

git tag -d tagname 删除本地一个标签
git push origin :refs/tags/tagname 删除远程标签

日志

配置别名

git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

查看日志

git lg file.c 查看file.c文件的提交记录
git lg dir/ 查看dir目录下提交记录
git lg --grep "opencl" 匹配日志信息中指定的的关键字
git show commitId 显示某次提交的详细信息
git blame somefile 显示文件各个部分的修改作者及相关提交信息
git blame -M somefile
git blame -C -C somefile

Git 工作流

Git 工作流介绍

Git分支管理策略
Git工作流程

工作流总结

版本场景：
不同项目需求既存在相同部分也存在不相同的功能点，并且在同一个项目中新功能的开发与发布版本 BUG 修改需要同时进行，但可能存在一种情形，需要发布解决测试工程师 BUG ，但不包含新功能的版本。

解决方案：

  • 在同一个项目创建 master 和 develop 两个分支，其中 master 分支用于版本的发布和测试 BUG 的修复，develop 分支用于新特性开发。

  • 当新特性开发完成需要发布版本时，将 develop 分支对应的内容合入到 master 分支，并在每次发布版本时对最新的发布 commit 记录添加 tag 标签。

  • 在 master 分支修复 BUG 的 commit 也需要合并到对应的 develop 分支，然后再进行新特性的开发。

  • 当不同项目的共同部分出现 BUG 时，选择其中一个项目对 BUG 进行解决，然后合并到所有需要修复 BUG 的分支。

缺点：
在一个项目中存在用于发布版本和 BUG 修复的 master 分支以及新特性开发的 develop 分支，当 BUG 修复和新特性开发涉及的共同部分容易造成冲突时，将会加大合并的工作量。因此，在开发过程中，主要模块的划分，新功能开发尽量不影响原有功能模块。

改进方案：
对不同项目的共同部分进行提炼，形成与项目无关的公共组件，作为项目的子模块，从而解决公共部分出现 BUG , 需要修复后再合入到所有分支的情形。

其他操作

临时忽略文件

git update-index --assume-unchanged file.c # 临时忽略文件
git update-index --no-assume-unchanged file.c # 解除临时忽略文件
git ls-files -v # 列出所有文件状态
git ls-files -v| grep '^h' # 查看临时忽略文件

参考资料

Git教程
Pro Git
Git分支Rebase详解
Git Merge和Git Rebase小结

扫一扫，分享到微信

微信分享二维码

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

能剒削柱梁谓之木匠<br>能穴凿穴坎谓之土匠<br>能雕琢文书谓之史匠<br>能搬砖撸码谓之码匠