看branch 的 remote track

看目前所有branch 的 track 狀態： $ git branch -vv 其中，有track 的，會顯示在 [ ] 中。

checkout & track remote branch

一般只要沒有混淆的地方(重複名稱，已經checkout.. etc)，直接 checkou remote branch 會自動設定 track。
但是有混淆的時候，就要手動了。

要 checkout remote branch ，並且設好 track (push, pull target)，可以用： $ git checkout --track -b merge10.4 aosp/merge10.4

---

• http://gitready.com/intermediate/2009/01/09/checkout-remote-tracked-branch.html

new project, clone from remote repo with specific name

如果要create 一個 new git，但是要從 remote 拿code，又要指定 remote 的name
(例如 android framework project 有自己 create 的新 project folder，就會需要這樣).

用 git clone 也可以，但是用這樣好像比較合理：

git init git remote add myserver git://..... git pull myserver

---

ref: http://blog.opsb.co.uk/instant-remote-git-repository-using-ssh

rebase

rebase 和　merge 一樣，都是要整合另一個 branch 的內容，
rebase 有一點 "管理 commit " 的意味。

---

如果把git 的每一次 commit 都當作一個 patch。

merge 會依照每個 patch 的時間，依序把merge 的兩個 branch 的 patch 一一上到source。
所以merge 完，兩個 branch 的 commit 有可能會穿插.


rebase 的話，就一律先上另一個branch 的 commit ，然後再上自己的 commit。

這在系統廠的工程師比較合用。

因為系統廠都是拿 vendor 的　bsp 來改。
所以當 vendor 有新版bsp 時，如果作 merge，
自己的修改和 vendor 的修改就會混在一起，
merge 時的 conflict 也會比較多(?)，因為有可能是 vendor 的commit 的 conflict，所以會比較不好 resolve。

如果是用 rebase 的話，至少第一步，vendor 的 new bsp 的 commit一定都上得去。
在自己的commit 才會發生 conflict，
這樣因為 conflict 是在自己的 修改，會比較好 resolve。

use ssh login with username

語法就是： $ git clone ssh://charles@servername/~/mysourcecode .. 可以用 ~ 就不用寫一堆 /home/charles/...

另外也可以指定 port，一樣，寫 sername:port

---

ref:
http://stackoverflow.com/questions/2433049/git-clone-using-ssh-cant-find-repository