免登錄轉自：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下也可以設置。