?
?
實現(xiàn)支持多選功能的選擇器（UIPickerView）
?
(實現(xiàn)可以多選的Picker效果)[http://www.code4app.com/thread-4525-1-1.html]
??_?? 20170406
ó
óó
??
?
從 ALAssets 到 PHAssets.
?
??
?
唐 旭 松：
梔子花、 與 桂花，
香氣 濃烈。
????
三道 git 面試題及其解答，google 風(fēng)格
第一題: 把配置文件推送到了遠程倉庫，怎樣刪除遠程倉庫的該配置文件，本地還要用到這個文件。
這種操作失誤，比較常見。一般這樣解決:
git rm --cached filename
echo filename >> .gitignore
先解釋第二步，本地需要，遠程倉庫不需要，肯定是要把那個文件寫入 .gitignore 文件里面。
否則以后還要刪除。
第一步則是把該文件從 git 的暫存區(qū)域中刪除。暫存區(qū)域，就是 index 區(qū)域。
見一下親人:
git 三個區(qū)，git rm filename, 會把文件從工作區(qū) Working Directory 和暫存區(qū)域 Staging Area 中刪除。本地還要用，就不能這么搞。
git rm --cached filename， 則把文件從暫存區(qū)域 Staging Area 刪除，保留工作區(qū)的，我們一般編輯見到的。
這種情況就是已經(jīng) commit 了，生成快照，文件進了版本庫 Commit History，然后 push, 遠程庫與本地庫同步一下。
這個時候，這個 push 到遠程，無效。因為沒有新的快照，也就是沒有新的 commit id. 本地與遠程的歷史 log 是一致的。
修改文件，add 再 commit, push 提交過去，就會生效。
第二題: git 如何解決代碼沖突
解決沖突三連
git stash
git pull
git stash pop
操作就是把自己修改的代碼隱藏，然后把遠程倉庫的代碼拉下來，然后把自己隱藏的修改的代碼釋放出來，讓 git 自動合并。接著找 <<<<<<<, 哪里沖突哪里改。
如果要代碼庫的文件完全覆蓋本地版本,
git reset --hard
git pull
前面兩招挺管用的，場景就是合作的遠程倉庫上，別人做了一些改動，我沒有 commit , 然后把別人的 commit 拉下來。
剛進入公司的時候，沒辦法，我也經(jīng)常這么做
然后加強版就來了
場景就是合作的遠程倉庫上，別人做了一些改動，我在本地也做了一些 commit , 然后把別人的 commit 拉下來，再把我的更改添加上去。接著找 <<<<<<<, 哪里沖突哪里改。
這個時候，先檢查一下我的本地倉庫與合作的遠程倉庫的最近的一個共同 commit id.
git reset commit id
git stash
git pull
git stash pop
git reset commit id 的作用是取消暫存文件。將 HEAD 的指針指向 commit id，修改了暫存區(qū)域 Staging Area 和版本庫 Commit History，工作區(qū)沙盒 Working Directory 保持原樣。
親人來了，看圖加深一下理解:
git reset commit id就是 git reset -mixed commit id，移動 HEAD，更新索引，即更新 staging area。移動 HEAD 分支的指向，使索引看起來像 HEAD。效果上看，就是取消了 commit id 以后的，commit .
git reset --soft commit id，就是移動 HEAD。移動 HEAD 分支的指向，本質(zhì)上是撤銷了上一次 git commit 命令。 當(dāng)你在運行 git commit 時，Git 會創(chuàng)建一個新的提交，并移動 HEAD 所指向的分支來使其指向該提交。
當(dāng)你將它 reset 回 HEAD~（HEAD 的父結(jié)點）時，其實就是把該分支移動回原來的位置，而不會改變索引和工作目錄。
git reset --hard commit id, 移動 HEAD，更新索引，更新工作目錄。三件事情，全做了。前兩件事情，已經(jīng)說了。更新工作目錄，讓工作目錄看起來像索引。從效果上看，就是撤銷一切修改，本地文件狀態(tài)同 commit id 的那時候。
第三題: 什么時候合并分支用 git rebase, 不用 git merge ?
git rebase 和 git merge 都可以用于合并分支，從 feature 分支上，取得新的提交 commits , 然后運用到 master 分支上（當(dāng)然運用到其他分支上也行）。
但是路子不同
merge 是合并，rebase 是變基
變基怎么變?
看圖可知: git rebase 有一個移動 base , 改變合并基準(zhǔn)的操作
直觀的理解: git rebase 做的事情，就是先移指針，再移結(jié)點。
先移指針就是就先 master 分出的 feature 分支的 commit id, 是 feature 分支的基準(zhǔn) base.
在 feature 分支上 git rebase master,就把 feature 分支的基準(zhǔn) base 移動到 master 分支最新的 commit id 上。
再移結(jié)點，就是把 feature 分支上新增的提交 commit id ，放到新的 base 結(jié)點后面。準(zhǔn)確一些，就是把 feature 分支上新做的修改操作，重新應(yīng)用到 master 分支的 HEAD 結(jié)點上。
舉個例子:
合并分支前:
A <- B <- C [master]
^
\
D <- E [branch]
根結(jié)點是 A, 最初是 A ， 在 A 狀態(tài)，分出去了分支 branch
git merge 是這樣合并的:
A <- B <- C
^ ^
\ \
D <- E <- F
提交到 C 的 master 分支和提交到 E 的 branch 分支，直接合并，一般是合并到 master, 有沖突解決沖突。
看圖可知: 采用 git merge ，不改變原來的 commit id, 會產(chǎn)生新的提交 commit id
項目協(xié)作成員比較多，一般需要使用 git rebase
如果使用 git merge ，很可能這樣，
這樣看，就很不舒服。需要采用 git rebase 修改歷史:
git rebase 是這樣合并的:
A <- B <- C <- `D` <- `E`
把 feature 分支（ 例子中是 branch 分支）的提交 commits ，移動到 master 分支的頂端。
使用 rebase, 看起來更加 nice, 更加直觀，歷史就是一條直線嘛，沒什么枝枝岔岔的。
看圖可知: 使用 rebase 后，把 feature 分支上 commit 拿來后，commit id 改掉了。并且沒有創(chuàng)建合并的公共節(jié)點 commit id
有的團隊采用 git rebase 工作流，有的采用 git merge 工作流，git rebase 工作流要求對 git 的理解深一些，商用多一些, feature 做好了，用 git rebase 合并。
這樣加 feature 怎么加的，看 log 比較明朗。否則看 log, 上一條 feature A, 下一條 feature B , 不是很職業(yè)程序員。
git rebase 工作流，一般這么實操，
在 feature 分支上 git rebase master，
切到 master 分支上后， git merge feature, 這時候 merge 也沒做什么事情，就是把 master 分支的 HEAD 結(jié)點，移動到 feature 的 HEAD 結(jié)點, 這個分支這時候狀態(tài)同步了。
git merge 工作流民用挺合適的，他的設(shè)計非常符合直覺，玩 github 開源，比較合適。因為多人寫作，git flow 工作流，不是很好統(tǒng)一
如果你采用 git rebase 工作流，你團隊其他人不知道，你這么搞，commit id 修改了，與他們本地庫的對不上，你們對你的意見可能會比較大
畢竟 git 采用分支，就是不冒犯別人代碼的意思
