在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一般

連通性測試，如GitHub: ssh -T [email protected] , 如果能連通，會提示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 [email protected] 就不行了(原因在於host不匹配[github.com != github_user1]，就無法進一步找到金鑰檔案)，這裡需改為 ssh -T [email protected]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. 

 -------符號連結設定-------

 core.symlinks 

需要設定該配置為true，才能讓git跟隨符號連結到實際內容。否則git將符號連結視為文字檔案（內容就是連結資訊）。

Windows Vista及以上版本是支援符號連結的。該配置項在Windows下也可以設定。