SourceTree 免登录跳过初始设置 与 SSH Key配置 与 换行符配置

免登录转自:http://www.cnblogs.com/xiofee/p/sourcetree_pass_initialization_setup.html

在SourceTree的配置目录新建(或修改)accounts.json为如下内容。配置目录一般位于:C:\Users\Administrator\AppData\Local\Atlassian\SourceTree,该目录需先启动一次SourceTree才会被生成(一般安装完SourceTree后,运行下,提示登录时就可以退出了,此时配置目录已经被生成)!

accounts.json:

[
  {
    "$id": "1",
    "$type": "SourceTree.Api.Host.Identity.Model.IdentityAccount, SourceTree.Api.Host.Identity",
    "Authenticate": true,
    "HostInstance": {
      "$id": "2",
      "$type": "SourceTree.Host.Atlassianaccount.AtlassianAccountInstance, SourceTree.Host.AtlassianAccount",
      "Host": {
        "$id": "3",
        "$type": "SourceTree.Host.Atlassianaccount.AtlassianAccountHost, SourceTree.Host.AtlassianAccount",
        "Id": "atlassian account"
      },
      "BaseUrl": "https://id.atlassian.com/"
    },
    "Credentials": {
      "$id": "4",
      "$type": "SourceTree.Model.BasicAuthCredentials, SourceTree.Api.Account",
      "Username": "",
      "Email": null
    },
    "IsDefault": false
  }
]

 

 -------SSH Key-------

要想ssh私钥和Linux下的通用,要将SourceTree一般选项下的SSH Client类型改为OpenSSH。 然后上面的SSH Key选择私钥路径(注意不是公钥):

 

连通性测试,如GitHub: ssh -T git@github.com , 如果能连通,会提示Hi xxx! You've successfully authenticated...

然而,如果你在SourceTree里指定的密钥路径不是默认路径(c:\Users\{username}\.ssh)或 私钥名称不是默认的id_rsa,SourceTree自己能正常工作,然而其Terminal命令行窗口却会无法工作,报错:Permission denied (publickey)。ssh -Tv xxx可以看到输出的详细信息里,终端查找的key路径依然是默认路径和默认私钥名id_rsa。

解决办法是在默认路径(c:\Users\{username}\.ssh)下建立名为config文件,内容:

Host *
    IdentityFile D:\MyKeys\github_id_rsa

可以更精确点, 如:

Host github_user1
    HostName github.com
    User user1
    Port 22
    IdentityFile D:\MyKeys\github1_id_rsa

Host github_user2
    HostName github.com
    User user2
    Port 22
    IdentityFile D:\MyKeys\github2_id_rsa

Host bitbucket.org
    HostName bitbucket.org
    IdentityFile D:\MyKeys\bitbuckrt_id_rsa

Host *
    IdentityFile D:\MyKeys\public_id_rsa

Host后面只是别名 (*特殊),真实的host地址应由HostName来指定,我们ssh连接时,可以且必须用别名取代真实的host,比如原本 ssh -T git@github.com 就不行了(原因在于host不匹配[github.com != github_user1],就无法进一步找到密钥文件),这里需改为 ssh -T git@github_user1 等;如果是要登录到远程主机,可以直接 ssh 别名 。如果/etc/hosts设置了主机别名,config里的Host建议与之保持一致,其它时候没什么特殊情况,一般建议直接将Host与HostName保持一致!

如果远端服务器ssh端口不是22,可用Port来指定。

虽然可以用ssh -i选项指定私钥文件 或 用ssh-add命令添加额外的私钥文件,但用config文件配置灵活性更高!

 

 -------换行符设置-------

 core.autocrlf 

通过git config --list查看所有配置的值,同一配置可能有多个相同的值(global、local repo),后者覆盖前者。用 git config core.autocrlf 显示其最终有效值。

可选值: true false input

实例: git config --global core.autocrlf false  // --global若省略,则设置只对当前repo有效

true: 检出时会将文件的lf转为crlf, 提交时会把文件中的crlf转为lf。。。终于能用记事本正确查看工作区文件内容了~( 还用记事本? :-D )

false: 检出或提交时都不会对文件换行符进行转换,原本是什么就是什么。 

input:从工作区放到仓库里(input)时,即提交时会将文件里的crlf转为lf;但检出时,不会进行转换。

在Windows下,若将其设置false,这可能会导致仓库内文件的代码换行符混乱不一致。而用true或input能使得仓库里的文件换行符都是lf。

// 即使如此, 我个人仍使用false。
1、是为了编辑时尽量不用\r\n,而是使用各平台统一的\n。
2、即使提交后的代码换行符不一致,也可以修改换行符后重新提交。
3、当前Visual Studio 2017支持.editorconfig。
4、如果提交的代码包含二进制文件,转换可能会导致文件损坏。。。

那么何时用true,input呢?

不管是true或input都不会影响提交后的仓库代码换行符。这要根据情况来选择。。。有些工程可能最好是input,比如某大的工程里面包含有一些批处理脚本文件,编译时需要自动调用相关工具对脚本进行处理,然而处理这些脚本的工具不能很好地识别crlf,将导致出错。这时就不应该设置core.autocrlf为true了,应该设为input。

上面的这个问题延伸开来,如果一些Windows平台下的批处理工具只能很好地识别crlf,不能很好地识别lf,那么我们就不应该设core.autocrlf为true或input了[即便true检出时自动转crlf,但你上传后,(别人core.autocrlf配置不同)再检出后就不一定保证会有正确的crlf了],而是false。

有时设core.autocrlf为true后,提交时产生以下warning:

warning: LF will be replaced by CRLF in XXX.c.
The file will have its original line endings in your working directory.

有人可能会疑问,不是应该 warning: CRLF will be replaced by LF in XXX.c. ,为什么是 warning: LF will be replaced by CRLF in XXX.c. 

的确,这个消息有误导性,具体见:Windows git “warning: LF will be replaced by CRLF”, is that warning tail backward?

 

 -------符号链接设置-------

 core.symlinks 

需要设置该配置为true,才能让git跟随符号链接到实际内容。否则git将符号链接视为文本文件(内容就是链接信息)。

Windows Vista及以上版本是支持符号链接的。该配置项在Windows下也可以设置

 

posted @ 2017-01-03 10:22 sfqtsh 阅读(...) 评论(...) 编辑 收藏