免登录转自：http://www.cnblogs.com/xiofee/p/sourcetree_pass_initialization_setup.html
在SourceTree的配置目录新建(或修改)accounts.json为如下内容。配置目录一般位于：C:UsersAdministratorAppDataLocalAtlassianSourceTree，该目录需先启动一次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:MyKeysgithub_id_rsa
可以更精确点, 如：
Host github_user1 HostName github.com User user1 Port 22 IdentityFile D:MyKeysgithub1_id_rsa Host github_user2 HostName github.com User user2 Port 22 IdentityFile D:MyKeysgithub2_id_rsa Host bitbucket.org HostName bitbucket.org IdentityFile D:MyKeysitbuckrt_id_rsa Host * IdentityFile D:MyKeyspublic_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、是为了编辑时尽量不用 ，而是使用各平台统一的 。 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下也可以设置。