Git笔记

1、为不同项目配置不同的密钥

        在.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

可能遇到的问题：

• 执行ssh免密码登录时报如下的错误：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

2、设置仓库地址代理

        在用户目录下，编辑.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

3、fast forward 模式

        在多人协同开发时，在推送到远端时，经常会看到包含fast forward的警告信息。简单来说就是提交到远端的代码必须是按照时间顺序。比如：

• 小明从远端拿到代码后，对文件file1进行了修改，然后提交并推送到了远端。
• 小红在小明之前就拿到了远端代码，在小明推送成功后也对文件file1进行了修改，本地提交后，要推送到远端时会收到含有fast forward的警告信息，提醒小红非快进方式的更新被拒绝，需要先从远端拉取到最新版本，合并后再推送。

        fast forward模式能够保证不会强制覆盖掉他人的提交，确保了多人协同开发。尽量不要使用no fast forward方式提交代码。

4、rebase 操作后推送远端分支不成功

        这几天工作中在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时会报错。
解决办法
        有以下两种情况：

• feature分支只有一个人在上面开发
          此时可以执行git push --force origin feature命令直接进行强制推送，--force选项可以理解为使用本地分支的状态去覆盖掉远端分支的状态，也就是执行后，本地分支怎样，远端分支就怎样。
• feature分支有多人在上面开发
          此时如果贸然使用--force选项，则可能会覆盖掉其他人提交的风险。比如：小明和小红两个人同时在feature分支上进行开发，小明已经在本地feature上提交了一部分代码并推送到远端，而此时小红在本地执行了rebase操作，她要推送到远端就必须使用--force选项，而她推送成功后就会覆盖掉小明提交的代码，这种情况下，推荐使用另外一种更安全的命令git push --force-with-lease origin feature，该命令在强制覆盖前会进行一次检查，如果其他人在该分支上由提交，则会有一个警告，这样可以避免覆盖其他人提交的风险。

5、Pull Request 和 Merge Request 的区别

        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。

6、core.autocrlf 配置说明

        假如你正在Windows上写程序，又或者你正在和其他人合作，他们在Windows上编程，而你却在其他系统上，在这些情况下，你可能会遇到行尾结束符问题。这是因为Windows使用回车和换行两个字符来结束一行，而Mac和Linux只使用换行一个字符。虽然这是小问题，但它会极大地扰乱跨平台协作。

• Git可以在你提交时自动地把行结束符CRLF转换成LF，而在签出代码时把LF转换成CRLF。用core.autocrlf来打开此项功能，如果是在Windows系统上，把它设置成true，这样当签出代码时，LF会被转换成CRLF：git config --global core.autocrlf true。
• Linux或Mac系统使用LF作为行结束符，因此你不想Git在签出文件时进行自动的转换；当一个以CRLF为行结束符的文件不小心被引入时你肯定想进行修正，把core.autocrlf设置成input来告诉Git在提交时把CRLF转换成LF，签出时不转换：git config --global core.autocrlf input，这样会在Windows系统上的签出文件中保留CRLF，会在Mac和Linux系统上，包括仓库中保留LF。
• 如果你是Windows程序员，且正在开发仅运行在Windows上的项目，可以设置false取消此功能，把回车符记录在库中：git config --global core.autocrlf false。