赞
踩
在.ssh
目录下创建config
文件。配置选项:
Host
,仓库网站的别名(必须)。User
,仓库网站上的用户名(随意)。IdentityFile
,私钥的绝对路径(必须)。# 配置github.com
Host github.com
User zhangsan
IdentityFile C:\Users\Microsoft\.ssh\id_rsa_github_proj1
# 配置gitee.com
Host gitee.com
User wangwu
IdentityFile C:\Users\Microsoft\.ssh\id_rsa_gitee_proj1
可能遇到的问题:
Bad owner or permissions on .ssh/config
。chmod 600 config
sign_and_send_pubkey: signing failed: agent refused operation
。eval "$(ssh-agent -s)"
ssh-add
在用户目录下,编辑.gitconfig
文件,例如:
[credential]
helper = manager-core
[url "ssh://git@192.168.1.110:10081/"]
insteadOf = https://192.168.1.110/
[url "ssh://git@jh.test.com.cn:2345/"]
insteadOf = https://test.com/
[core]
autocrlf = false
[user]
name = jaronho
email = jaronho@jh.com
在多人协同开发时,在推送到远端时,经常会看到包含fast forward的警告信息。简单来说就是提交到远端的代码必须是按照时间顺序。比如:
fast forward模式能够保证不会强制覆盖掉他人的提交,确保了多人协同开发。尽量不要使用no fast forward方式提交代码。
这几天工作中在rebase
后,一直无法推送到远端分支,举个例子:一开始只有一个master主分支,假设上面有3个提交,仓库图为:
A-->B-->C(master)
假设开发人员在C提交上开出新的分支为feature,并在其上进行了2次提交,假设此过程中master主分支也发生了变化(也有2次提交),仓库图为:
A-->B-->C-->C1-->C2(master)
\
D-->E(feature)
在本地feature分支执行git rebase master
命令后,本地的仓库图为:
A-->B-->C-->C1-->C2(master)
\
D-->E(feature)
而此时远端feature分支的仓库图还是开始的初始状态。此时执行git push origin feature
命令把本地feature分支推送到远端时会报错。这是因为git
的push
操作默认是假设远端分支和本地分支可以进行fast-forward模式的合并操作,换句话说,就是push
操作假设远端分支和本地分支的唯一区别是本地分支多了几个新的提交,而远端没有,仓库图为:
A-->B-->C(远端feature)
\
D-->E(本地feature)
但是由于进行了rebase
操作,现在远端分支和本地分支的仓库图为:
A-->B-->C-->C1-->C2-->D-->E(本地feature)
\
D-->E(远端feature)
这种情况下无法进行fast-forward模式的合并操作,所以执行git push origin feature
时会报错。
解决办法
有以下两种情况:
git push --force origin feature
命令直接进行强制推送,--force
选项可以理解为使用本地分支的状态去覆盖掉远端分支的状态,也就是执行后,本地分支怎样,远端分支就怎样。--force
选项,则可能会覆盖掉其他人提交的风险。比如:小明和小红两个人同时在feature分支上进行开发,小明已经在本地feature上提交了一部分代码并推送到远端,而此时小红在本地执行了rebase
操作,她要推送到远端就必须使用--force
选项,而她推送成功后就会覆盖掉小明提交的代码,这种情况下,推荐使用另外一种更安全的命令git push --force-with-lease origin feature
,该命令在强制覆盖前会进行一次检查,如果其他人在该分支上由提交,则会有一个警告,这样可以避免覆盖其他人提交的风险。 GitHub上要请求代码合入时用到了Pull Request
的概念,而GitLab上则用到了Merge Request
的概念。这两个概念有什么区别呢?GitLab的官方说明为:
Merge or pull requests are created in a git management application and ask an assigned person to merge two branches. Tools such as GitHub and Bitbucket choose the name pull request since the first manual action would be to pull the feature branch. Tools such as GitLab and Gitorious choose the name merge request since that is the final action that is requested of the assignee.
大概意思就是Merge Request
和Pull Request
是同一个东西,仅仅只是名字不一样。一般我们执行分支合并,需要执行下面两个命令:
git pull
,拉回需要合并的分支。git merge
,合并进目标分支。 Github选择了第一个命令来命名,叫Pull Request
。Gitlab选择了最后一个命令来命名,叫Merge Request
。
假如你正在Windows上写程序,又或者你正在和其他人合作,他们在Windows上编程,而你却在其他系统上,在这些情况下,你可能会遇到行尾结束符问题。这是因为Windows使用回车和换行两个字符来结束一行,而Mac和Linux只使用换行一个字符。虽然这是小问题,但它会极大地扰乱跨平台协作。
CRLF
转换成LF
,而在签出代码时把LF
转换成CRLF
。用core.autocrlf
来打开此项功能,如果是在Windows系统上,把它设置成true
,这样当签出代码时,LF
会被转换成CRLF
:git config --global core.autocrlf true
。CRLF
为行结束符的文件不小心被引入时你肯定想进行修正,把core.autocrlf
设置成input
来告诉Git在提交时把CRLF
转换成LF
,签出时不转换:git config --global core.autocrlf input
,这样会在Windows系统上的签出文件中保留CRLF
,会在Mac和Linux系统上,包括仓库中保留LF
。false
取消此功能,把回车符记录在库中:git config --global core.autocrlf false
。Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。