git常规应用策略
git的核心思想
Git 的配置
初次运行Git前的配置
Git自带一个git config的工具设置Git外观和行为的配置变量。每台计算机只需配置一次,程序升级时会保留配置信息。可以通过命令修改它们。
- /etc/gitconfig文件:
包含系统上每一个用户及他们仓库的通用配置。如果使用带有–system选项的git config时,它会从此文件读写配置变量。 - /.gitconfig或者/.config/git/config文件:
只针对当前用户。可以传递–global选项让Git读写此文件。 - 当前使用仓库的Git目录中的config文件(就是.git/config):
针对该仓库。
每一个级别覆盖上一级别的配置,所以.git/config的配置变量会覆盖/etc/gitconfig中的配置变量。
用户信息配置
文本编辑器配置
检查配置信息
/**
* 1. 列出所有Git当时能找到的配置
*/
git config --list
/**
* 2. 检查Git的某一项配置
*/
git config <key>:
eg: git config user.name
获取帮助
获取帮助信息,无需联网
git help <verb>
git <verb> --help
man git-<verb>
eg: git help config
本地工程、仓库、分支和远程工程、仓库、分支的创建
在本地目录创建仓库并与远程仓库关联的方式一共有两种情况。1,本地目录空,远程仓库已经由他人创建。2,本地目录空,远程仓库由自己创建 。3,本地目录不空(已经有初版工程),远程仓库还未创建。
前两种情况,都是采用clone方式即可创建与远程仓库相关联的本地仓库。第三种情况,则需要关联、合并本地、远程仓库。
具体操作, 因为第一种实在没有什么操作,只有"git clone …",所以,我们只针对第三种情况说明。
下面是在远程仓库GitHub上创建工程的时候,添加有内容(readme),会造成远程仓库和本地仓库文件不一致时,如何操作。
- GitHub端创建远程仓库
- 在本地工程目录,创建本地仓库
git init
- 添加本地文件
git add .
- 提交本地文件
git commit -m "message" [./filename] -a
以上都是在我们本地的工作,现在我们把更改推送到远程服务器上
-
关联GitHub上面的项目
1. git remote -v //查看远程仓库 2. git remote rm origin //删除远程仓库 3. git remote add origin {url} //添加远程仓库, origin为给远程仓库起的名字 4. git pull origin master --allow-unrelated-histories //如果在3就执行pull的话,远程仓库和本地仓库不相干,文件不匹配,所以警告无法合并。 //所以,第一种解决方法:从远程仓库拉下来代码,本地要加入的代码放到远程仓库下载到本地的库,然后提交 //这样的话,你基于的库就是远端的库。 //第二种解决方法:就是使用4中的强制将两段不相干的本地、远程分支强行合并 5. git push -u origin master //如果远程仓库是空的,我们第一次推动master分支时,加上参数-u, //git不但会把本地的master分支内容推送到远程新的master分支,还会将本地的master分支和远程的master //分支关联起来。
下面是在创建远程仓库(github)时,没有添加任何文件。
GitHub会尽心的有如下提示:
其中就有“or create a new repository on the command line”
然后,在git中做相应命令行操作即可实现首次仓库的创建。与上面方法的区别就在于,远程仓库为空,可以忽略pull远程仓库和本地仓库不一致问题。下面是实操效果图:
值得一提的是,其中github提示了一行”git branch -M master“;
通过”git help branch“查看git branch命令,有如下解释:
就是对分支重新命名了。据说是因为黑人的政治正确,master变成敏感词汇了,哈哈。
下面重新刷新GitHub远程仓库,看是否本地仓库已经推送到远端。
没问题!
本地工程、仓库、分支的维护 和 远程工程、仓库、分支的维护
版本的回退、前进
- 查看历史版本 “git reflog”
- 版本的前进和回退
- 基于索引值操作(既能前进也能后退) “git reset --hard [索引值]”
- 使用^符号(只能后退) "git reset --hard HEAD^ "。 [注]:一个^表示回退一步, n表示回退n步
- 使用~符号(只能回退) “git reset --hard HEAD~n”。 [注]:表示后退n步
- reset 命令的三个参数对比
- –soft 参数: 仅仅在本地库移动HEAD指针
- –mixed参数: 在本地库移动HEAD指针、重置暂存区
- –hard参数: 在本地仓库移动HEAD指针、重置暂存区、 重置工作区
checkout
- 工作区有更改和commit本地仓库不一致,需要清除工作的更改操作,使用“git checkout .”,或者“git checkout – filename”
- 放弃工作区和暂存区的所有修改, 使用“git checkout -f”
- 进行本地的分支切换,使用“git checkout [branch name]”。
- 远程分支的切换, 使用“git checkout -b 本地分支名 origin/远程分支名”
branch
pull
push
user1 在分支A 写代码写了一半,有另一个开发者user2也开发了此分支,并已经push上去了。
那么,user1该怎么办呢?
1. git add .
2. git commit -m "xxxxxx"
3. git push
/* 由于user2也修改,并push了此分支,会引发冲突 */
4. git pull
/* 将user2 push的代码版本 拉下来,会自动与本地代码merge */
/* 解决merge 冲突 */
4.1. git add .
4.2 git commit -m "xxxxxx"
4.3 git push
【注解】:每次的push都会检验比对文件,并生成哈希值。如果检验有问题,会产生相应冲突,否则就是git逻辑上有漏洞了。
tag
查询标签
/* 当前仓库的所有标签 */
git tag
/* 符合模式的标签 */
git tag -l ‘v0.1.*’
/* 查看标签的版本信息 */
git show v0.1.2
创建标签
有两种类型的标签 : 轻量标签(lightweight)、附注标签(annotated)
【轻量标签 】: 只是某个commit 的引用,可以理解为是一个commit的别名;
【附注标签】 :是存储在git仓库中的一个完整对象,包含打标签者的名字、电子邮件地址、日期时间 以及其他的标签信息。
它是可以被校验的,可以使用 GNU Privacy Guard (GPG) 签名并验证。
- 创建轻量标签
git tag 标签名 : 直接给当前的提交版本创建一个【轻量标签】
git tag 标签名 提交版本号 :给指定的提交版本创建一个 【轻量标签】
/* 以当前提交版本创建【轻量标签】 */
git tag v4.0
/* 以指定版本【7864852】创建【轻量标签】 */
git tag v3.0 7864852
- 创建附注标签
-a : 理解为 annotated 的首字符,表示 附注标签
-m : 指定附注信息
git tag -a 标签名称 -m 附注信息 :直接给当前的提交版本创建一个 【附注标签】
git tag -a 标签名称 提交版本号 -m 附注信息 :给指定的提交版本创建一个【附注标签】
/* 以当前提交版本创建【附注标签】 */
git tag -a v3.0-release -m "里程碑版本 3.0 正式发布"
/* 以指定版本【f568452】创建【附注标签】 */
git tag -a v2.0-release f568452 -m "里程碑版本 2.0 正式发布"
提交标签
通常的git push不会将标签对象提交到git服务器,我们需要进行显示的操作
/* 单个 */
git push origin v1.0.2
/* 所有 */
git push origin --tags
切换标签
git checkout [tagname] :切换到标签版本
git checkout -b [分支名称] [tagname] :现在这个标签基础上进行其他开发。 就是以标签指定的版本为基础版本,创建一个新分支,继续其他操作,即创建新分支。
/* 切换到标签版本 */
git checkout v5.0
/* 以标签为基础创建一个新分支 */
git checkout -b bug-fixed-3.0 v5.0-release
删除标签
git tag -d 标签名称:删除指定名称的本地标签
git push origin :regs/tags/标签名称 :删除远程标签
git push origin --delete 标签名称:删除远程标签
/* 删除本地标签 */
git tag -d v0.1.2
/* 删除远程标签 - 就像git push origin :branch_1 可以删除远程仓库的分支branch_1一样, 冒号前为空表示删除远程仓库的tag */
git push origin :refs/tags/v1.0.1
/* 删除远程标签 */
git push origin --delete v1.0.1
使用策略
merge
有冲突的情况说明。
-
user1 和user2 各改各的地方(相同文件),不冲突。
-
user1 和user2 各改各的文件,不冲突。
-
user1 移动文件,user2 不移动文件, git 不显示冲突。但是需要我们人为备注,注意。
-
user1 和user2 修改相同文件的相同地方,引起冲突,并且git提示冲突。
由于在merge过程中,不能仔细斟酌它默认保留的冲突代码是否是我们想要的,或者手动解决的冲突,是否完整,想要查看。可以通过以下操作查看。
a. 通过show命令
git log 查看merge 的哈希值
git show 查看更改
b. 通过git log -p
rebase
分支合并push
1.修改程序,commit “1.1.7”—》修改程序,commit “1.1.8”—》修改程序, commit “1.1.9”
2.右键本地仓库,bash here :git rebase -i HEAD~3 —>显示下图
按键‘i’—>进入编辑界面,底层有提示“-- INSERT --”
修改’pick xxxx’ —>‘squash xxxx’ ,如下图:
按Q退出编辑,然后输入:wq +enter键,保存退出编辑界面,运行后界面显示图下:
输入:wq ,保存退出vim界面,返回git命令界面,显示图下:
3,push合并的分支
在上面的git页面继续键入:
git push origin xxx指令
4,运行前后效果
前:
后:
发现只push了一个1.1.7节点,其实这一节点是1.1.7、1.1.8、1.1.9合并的。但是由于显示长度问题,只显示最早的信息描述。
点进去,效果如下:
git diff
git merge 之后有冲突,显示“|merging ”,想查看哪些文件冲突了,怎么办?
```cpp
git diff --name-only --diff-filter=U
```
参考官网【】
–name-only (仅仅列出改变的名字)
: show only names of changed files. The file names are often encoded in UTF-8.For more information see the discussion about encoding in the git-log[1] manual page.
–diff-filter=[(A|C|D|M|R|T|U|X|B)…[*]]
:
过滤器,U是仅仅显示Unmerged.