在 Github 上 git clone 某一 repository 时，它会给出两种选择： Clone with HTTPS 、Clone with SSH。这个选择决定了以后访问 remote repository 的时候，采用什么样的方式去提交 credential。Bitbucket 和 GitLab 同样有 Https 和 SSH 的选择。

Github Https & SSH

Https 和 SSH 的区别

就 Git 而言，https 和 ssh 的区别简单的说就是：

• https： git clone 和 git pull 无限制，git push 需要提供 credential，一般是你的 github（如果 remote repository 托管在 github 上的话）的用户名和密码；
• ssh：因为需要在托管平台上设置 ssh public key，所以要求你必须是该 repository 的拥有者或者管理员。git push 时，无需输入用户名，如果在生成 ssh key 的时候设置了密码，则需要输入密码，否则不需要。

选择过程中的一些建议

• 如果开发环境在 windows ，产品环境在 linux，建议在 windows 下使用 https，在 linux 下使用 ssh。除了 ssh 本身的限制，这个建议还考虑到其他两个因素：方便、安全。如果 linux 下使用 https，安全性没问题，但为了方便，当然希望在访问 remote repository 时可以免密码。关于这一点，网上大多数的解决方案是将用户名和密码包含在远程地址中，然后使用 git config --global credential.helper store 将 credential 信息以明文方式存储在 .git-credentials 文件中。这样一来，安全性不能保证。所以建议在 linux 下使用 ssh 方式。虽然 ssh key 的部署略微有点麻烦，但是一旦部署好，能同时保证安全性和便捷性。
  因为 linux 下使用了 ssh 方式，并且产品环境下的 ssh private key 不能轻易泄露。所以 windows 下建议使用 https 方式。windows 下有 git-credential-winstore 和 git-credential-manager-for-windows 用以存储 credential，所以安全性和便捷性同样可以保证。
• 如果有多人共同维护产品，ssh 无疑是最好的选择。因为多人维护，所以项目部署至产品环境，无论产品环境是 windows 还是 linux，需要一个统一的密码（即使这个密码为空）。如果使用 https 方式，必须以一个人的账号和密码作为 credential， 这样会有两个问题，一是不利于个人隐私的保护，二是如果此人出现人事变动，会带来不必要的麻烦。