Git使用
一.创建仓库
1.初始化仓库: git init
2.设置name和email(必须设置)
git config user.name "lmj"
git config user.email "xxxxxxx.com"
3.删除设置
git config --unset user.name
git config --unset user.emai
4.查看设置
git config -l
5.全局设置(创建的每个仓库都会添加这个设置)
git config --global user.name "lmj"
git config --global user.email "xxxxxxx.com"
6.删除全局设置
git config --global --unset user.name
注意: .git目录下不能有任何修改
二.管理git
注意: 工作区(和.git同级目录)中的文件add之后进入暂存区, commit之后进入版本库.
注意: HEAD不仅可以指向master分支, 还可以指向其它分支, HEAD所指向的分支为工作分支.
1.修改操作
a)git add 文件名
注意: 如果文件名为".", 表示所有文件
b)git commit -m "此处详细填写修改描述"
注意: 可以多次add, 一次commit.
2.查看提交记录: git log
如果想要使日志文件更加可观, 输入指令: git log --pretty=oneline
如果要图形,输入指令: git log --graph --abbrev-commit
3.查看上次提交之后是否修改: git status
如果要查看具体做了什么修改: git diff 文件名
注意: 修改之后要重新add, commit
4.版本回退: git reset [--soft | --mixed(默认) | --hard] [HEAD]
--soft: 只回退版本库, 暂存区和工作区不动.
--mixed: 回退版本库和暂存区, 工作区不动.
--hard: 回退版本库, 暂存区和工作区.
注意: --hard慎用,它会使工作区的内容回退(指定版本之后的提交都会消失).
如果回退之后后悔了, 可以回退之前的回退操作(前提是之前的HEAD还能找到).
如果命令 git log 找不到HEAD了, 可以使用git reflog
5.撤销修改
a)(只修改了工作区)将工作区的文件回退到上一次add(或者commit)的版本: git checkout -- 文件名
b)(修改了工作区和暂存区(使用了add))将工作区和暂存区回退到和版本区保持一致(回退到当前版本), 建议分为两步操作:
git reset [--mixed(可省略)] HEAD 文件名 (如果回退到上个版本,则将HEAD改为HEAD^)
git check -- 文件名
c)(全部修改了(使用了add, commit))全部回退到上一个版本(前提: 没有push):
git reset --hard HEAD^ 文件名 (如果回退到上上个版本,则将HEAD^改为HEAD^^)
6.删除版本库文件
方法1: 先使用rm把工作区的文件删除, 在使用add和commit
方法2: 实现使用git rm 文件名, 然后所有commit
三.分支
1.查看分支: git branch
2.创建分支: git branch 分支名
注意: 该分支是基于最近的一次commit而创建的, 所以指向最新的一次提交
3.切换HEAD指针: git checkout 分支名
注意: 如果是创建分支并切换,使用命名: git checkout -b 分支名
4.分支合并: 首先先把HEAD切换到master上, 使用命名git merge 分支名
5.删除分支: 首先把HEAD切换到其它分支, 然后使用命名: git branch -d 分支名
6.合并冲突: 两个分支对同一部分内容做了修改, 合并时不知道保留哪种修改, 此时需要在工作区中手动删除不需要的内容, 然后add+commit
7.合并时, 如果没有冲突, 默认使用Fast-forward模式, 日志无法区分是提交的还是合并的, 建议使用以下命名: git merge --no-ff -m "提交描述" 分支名
8.分支策略:
a)场景1: 在开发分支进行开发时, 主分支发现bug, 解决方法: 在开发分支下, 使用命令: git stash保存开发内容, 然后切换到主分支上, 创建修复bug分支, 修复完之后合并到主分支, 然后返回开发分支, 使用命名: git stash pop把新增的开发内容取到, 开发结束之后, 建议先将主分支的内容合并至开发分支, 在开发分支把冲突解决了, 再将开发分支合并至主分支.
b)场景2: 新增的功能不需要了,解决方法: 此时要强行删除开发分支, 使用命名: git branch -D 分支名
四.远程操作
1.将远程仓库克隆到本地, 输入命令: git clone 地址
注意: 不能克隆到本地仓库所在的目录. 如果要使用ssh协议, 则要在gitee平台上配置本地ssh公钥.
2.本地推送到服务器: git push origin 本地分支名(master):远程分支名(master)
注意: 如果本地分支名和远程分支名一致, 可以省略远程分支名
3.服务器拉回到本地: git pull origin 本地分支名(master):远程分支名(master)
注意: 如果本地分支名和远程分支名一致, 可以省略远程分支名
4.忽略特殊文件(.gitignore): 创建远程仓库时选择语言, 也可以在本地创建(不提交: *.后缀,
提交: !文件名.后缀)
注意: 被忽略的文件可以使用命令: git add -f 文件名 强制提交
五.标签tag(针对commit)
1.命令起别名: git config --global alias.别名 原名
注意: 原名可以是'整行命令'
2.创建标签: git tag 标签名(如v1.0) commitid(如果省略, 表示最近的一次commit)
注意: 如果需要标签表述, 使用命令: git tag -a 标签名 -m "描述信息" commitid(可省略)
3.查看标签: git tag
注意: 如果要看标签描述, 则要使用命令: git show 标签名
4.推送标签至远程服务器: git push origin 标签名
5.删除标签: git tag -d 标签名
如果要在远程仓库中删除, 使用命令: git push origin :标签名
六.多人协作
1.在本地创建新的分支并关联到远程仓库的分支, 使用命令:
git checkout -b 分支名 origin/分支名
注意: 关联好了之后可以直接使用git push/pull命令, 不用加参数
2.展现本地分支和远程仓库分支的关联关系, 使用命令: git branch -vv
3.解决远程仓库删除分支而本地仍然存在的问题:
输入命名: git remote show origin 查看情况
输入命令: git remote prune origin
七.Git Flow模型
1)5个分支
a)master 为主分支, 该分支为只读且唯一分支. 用于部署到正式发布环境, 一般由合并release 分支得到. 主分支作为稳定的唯一代码库, 任何情况下不允许直接在master分支上修改代码. 产品的功能全部实现后, 最终在master分支对外发布, 另外所有在master分支的推送应该打标签(tag)做记录, 方便追溯. master分支不可删除.
b)release为预发布分支, 基于本次上线所有的feature分支合并到develop分支之后, 基于develop分支创建. 可以部署到测试或预发布集群. 命名以release/开头，建议的命名规则: release/version_publishtime. release分支主要用于提交给测试人员进行功能测试. 发布提测阶段, 会以release分支代码为基准进行提测. 如果在release 分支测试出问题，需要回归验证 develop分支看否存在此问题. release分支属于临时分支, 产品上线后可选删除.
c)develop为开发分支, 基于master分支创建的只读且唯一分支, 始终保持最新完成以及bug修复后的代码. 可部署到开发环境对应集群. 可根据需求大小程度确定是由feature分支合并, 还是直接在上面开发(非常不建议).
d)feature分支通常为新功能或新特性开发分支, 以develop分支基础创建feature分支名以 feature/开头, 建议的命名规则: feature/user_createtime_feature. 新特性或新功能开发完成后, 开发人员需合到develop分支. 一旦该需求发布上线, 便将其删除.
e)hotfix分支为线上bug修复分支或叫补丁分支, 主要用于对线上的版本进行bug修复. 当线上出现紧急问题需要马上修复时, 需要基于 master分支创建hotfix分支.命名以hotfix/开头, 建议的命名规则: hotfix/user_createtime_hotfix. 当问题修复完成后, 需要合并到master分支和develop分支并推送远程. 一旦修复上线, 便将其删除.