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