Git
1、git pull 总提示让输入merge 信息
原因:当本地分支完成commit尚未push到远程时,远程仓库响应分支已经被另一个同事提交了一次或多次,当本地执行git pull origin xxx时 就会出现
解法:当执行git pull origin xxx
时添加参数--no-edit
git pull origin xxx --no-edit
这就避免了让你输入无用的merge信息了,自动保存并上传了默认的merge信息
2、gitlab上创建的分支git branch -a 查不到
解决:git同步版本库需要手操作。git fetch
3、创建分支命令 git branch ***
4、切换分支命令: git checkout ***
5、git checkout -b hotfix 创建并切换到hotfix分支 --->git commit -a -m 'fixed the broken email address' -->git checkout master-->git merge hotfix
6、删除临时创建的hotfix分支 git branch -d hotfix
https://blog.csdn.net/hudashi/article/details/7664631 git rebase 简介
7、git merge vs git rebase
变基 vs. 合并
在 Git 中整合来自不同分支的修改主要有两种方法:
merge
以及rebase
。合并:整合分支最容易的方法是
merge
命令。 它会把两个分支的最新快照(C3
和C4
)以及二者最近的共同祖先(C2
)进行三方合并,合并的结果是生成一个新的快照(并提交)。变基:提取在
C4
中引入的补丁和修改,然后在C3
的基础上应用一次。 在 Git 中,这种操作就叫做 变基(rebase)。 你可以使用rebase
命令将提交到某一分支上的所有修改都移至另一分支上,就好像“重新播放”一样。变基使得提交历史更加整洁。 你在查看一个经过变基的分支的历史记录时会发现,尽管实际的开发工作是并行的, 但它们看上去就像是串行的一样,提交历史是一条直线没有分叉。一般我们这样做的目的是为了确保在向远程分支推送时能保持提交历史的整洁——例如向某个其他人维护的项目贡献代码时。 在这种情况下,你首先在自己的分支里进行开发,当开发完成时你需要先将你的代码变基到
origin/master
上,然后再向主项目提交修改。 这样的话,该项目的维护者就不再需要进行整合工作,只需要快进合并便可。变基的风险
奇妙的变基也并非完美无缺,要用它得遵守一条准则:
如果提交存在于你的仓库之外,而别人可能基于这些提交进行开发,那么不要执行变基。
变基和合并的用法,到底哪种方式更好?
请注意,无论是通过变基,还是通过三方合并,整合的最终结果所指向的快照始终是一样的,只不过提交历史不同罢了。 变基是将一系列提交按照原有次序依次应用到另一分支上,而合并是把最终结果合在一起。
原则:只对尚未推送或分享给别人的本地修改执行变基操作清理历史, 从不对已推送至别处的提交执行变基操作,这样,你才能享受到两种方式带来的便利。
8、idea 删除.idea文件夹版本控制
在项目根目录下,右键鼠标选中Git Bash Here
输入git rm --cached 你的文件 或者输入git rm -r --cached 你的文件
git commit -m 'delete some remote files' git push
9、git 设置用户名和邮箱(Git Bash)\Git 当前项目设置 用户名、邮箱
$ git config –global user.name “github’s Name”
$ git config –global user.email “github@xx.com”
$ git config –list
如果你公司的项目是放在自建的gitlab上面, 如果你不进行配置用户名和邮箱的话, 则会使用全局的, 这个时候是错误的, 正确的做法是针对公司的项目, 在项目根目录下进行单独配置
找到当前项目所在的.git文件夹
$ git config user.name “your Name”
$ git config user.email “gitlab@xx.com”
$ git config --list
git config –list查看当前配置, 在当前项目下面查看的配置是全局配置+当前项目的配置, 使用的时候会优先使用当前项目的配置