SourceTree 免登录跳过初始设置 - 转

免登录转自：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。
、是为了编辑时尽量不用\r\n，而是使用各平台统一的\n。
、即使提交后的代码换行符不一致，也可以修改换行符后重新提交。
、当前Visual Studio 2017支持.editorconfig。
、如果提交的代码包含二进制文件，转换可能会导致文件损坏。。。

那么何时用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下也可以设置。