转载请标明出处:http://blog.csdn.net/zhaoyanjun6/article/details/70332707
本文出自【赵彦军的博客】
首先在 Android Studio 里面找到 命令行窗口,如下图所示:
git --version
结果:
git version 2.11.0.windows.1
git config --global user.name
结果:
zhaoyanjun
git config --global user.email
git config --global user.name '赵彦军'
git config --global user.email '[email protected]'
文件夹下初始化一个仓库,此时文件里会到一个.git
的隐藏文件夹
git init
git branch
可以看出,我的本地有两个分支:master 分支 、zhaoyanjun 分支。 master 分支 显示的是绿色,左侧有一个 * 号,表示,当前我们在 master 分支上操作。
git branch -a
效果如图所示:
可以看出,本地有两个分支(master、zhaoyanjun),红色的记录有4条,代表4条远程分支(laijian、master、zhaoyanjun、zhiqiang)。
git branch -r
创建 dev 分支。
git branch dev
切换 dev 分支为当前分支
git checkout dev
创建并切换 dev 分支。相当于 git branch dev
和 git checkout dev
的合集。
git checkout -b dev
把 当前根目录中的 loader1.png
添加在暂存区。 add 后面需要写 文件的相对路径。
git add loader1.png
把 image
目录下的 loader1.png
图片添加到暂存区
git add image/loader1.png
在 Android Studio 很多层级的目录文件中,如何获取文件的路径:
git add -A
git log
退出 log
q
git branch -d dev
删除本地仓库的 dev 分支
git push origin :dev
删除远程的 dev 分支
git rm 文件名
git pull
表示把你的本地当前分支里的每个提交(commit)取消掉,并且把它们临时 保存为补丁(patch)(这些补丁放到".git/rebase"目录中),然后把本地当前分支更新 为最新的"origin"分支,最后把保存的这些补丁应用到本地当前分支上。
git pull --rebase
git commit -a -m '修复一个bug'
git push origin master
git merge dev
git merge origin/dev
比较的是暂存区和工作区的差异
git diff
比较的是暂存区和历史区的差异
git diff --cached
比较的是历史区和工作区的差异(修改)
git diff master
git tag
git tag –d tag名字
git show tag名字
git tag 标签名
git tag 标签名 该版本ID
reset命令有3种方式:
git reset –mixed:
此为默认方式,不带任何参数的git reset,即时这种方式,它回退到某个版本,只保留源码,回退commit和index信息
git reset –soft:
回退到某个版本,只回退了commit的信息,不会恢复到index file一级。如果还要提交,直接commit即可
3:git reset –hard:
彻底回退到某个版本,本地的源码也会变为上一个版本的内容
1、 将本地的状态回退到和远程一样
git reset --hard origin/master
2、将暂存区里面的修改清空 , 回退到上一次提交的记录
git reset --hard
3、将本地的状态回退到 某个版本
git reset --hard 5230bb6
将本地状态回退到 5230bb6 这次的提交
很多时候,我们需要在自己的分支去完成一个新功能,中间会产生多个临时 commit , 如果我们不做处理,那么这些临时 commit 就会显得特别乱,现在交给大家一个技能,就是把多个 commit 合并成一个,然后提交。
下面用一张图说明:
从上图我们可以看出,我们在 v1版本发布
的基础上,又做了3个提交。我们现在用 rebase 命令把这三个提交合并成一个。
git rebae -i 160ce28
160ce28
为 v1版本发布
的git记录号,这里做参考,表示当前节点不参与合并
或者
git rebase -i HEAD~3
执行完这个命令后,我们将看到如下的合并信息。
上面未被注释的部分列出的是我们本次rebase操作包含的所有提交,下面注释部分是git为我们提供的命令说明。每一个commit id 前面的pick表示指令类型,git 为我们提供了以下几个命令:
pick:保留该commit(缩写:p)
reword:保留该commit,但我需要修改该commit的注释(缩写:r)
edit:保留该commit, 但我要停下来修改该提交(不仅仅修改注释)(缩写:e)
squash:将该commit和前一个commit合并(缩写:s)
fixup:将该commit和前一个commit合并,但我不要保留该提交的注释信息(缩写:f)
exec:执行shell命令(缩写:x)
drop:我要丢弃该commit(缩写:d)
根据我们的需求,我们将commit内容编辑如下:
然后保存退出。执行退出命令后,会出现一个修改提交信息的窗口
提交信息如果不需要修改,那么我们直接退出就可以了。下面我们来做一个修改的操作,如下:
修改完成后,保存退出。git 会帮我们做好合并的工作,如下:
一般情况下,在 commit 的时候,是要求必须写 commit 日志,否则不能 commit . 那么 commit 日志也是需要规范的。日志格式一般为:
type( scope ): subject
空行
body
空行
footer
type(必需)、scope(可选)和subject(必需)。
type
用于说明 commit 的类别,只允许使用下面7个标识。
feat:新功能(feature)
fix:修补bug
docs:文档(documentation)
style: 格式(不影响代码运行的变动)
refactor:重构(即不是新增功能,也不是修改bug的代码变动)
test:增加测试
chore:构建过程或辅助工具的变动
如果type为 feat 和 fix ,则该 commit 将肯定出现在 Change log 之中。其他情况(docs、chore、style、refactor、test)由你决定,要不要放入 Change log,建议是不要。
scope
scope用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同。一般有三个可以选择。
subject
subject是 commit 目的的简短描述,不超过50个字符。
以动词开头,使用第一人称现在时,比如change,而不是changed或changes
第一个字母小写
结尾不加句号(.)
body
具体的修改信息 应该尽量详细
footer
放置写备注啥的,如果是 bug ,可以把bug id放入
效果图如下图所示:
http://www.ruanyifeng.com/blog/2015/12/git-cheat-sheet.html