[工作筆記] git filemode 設定，避免檔案權限不同而進 git status

最近工作常常在 windows 跟 Mac, Linux 上切換來切換去，發現在 Mac 掛磁碟機近來的 Repo 莫名其妙都進 git status 變成需要 diff 的檔案，明明也沒修改什麼，也有可能是因為用 afp 掛進來的，然後我也完全忘記有檔案權限這件事情，還好同事英明，快速指出原因。

要讓 git 忽略這個問題，只要設定 git 的 filemode 就行:

git config core.fileMode false

若想要設定成全域，加上 --global 就可以。

參考:

How do I make Git ignore file mode (chmod) changes?

git tips: 设置filemode，避免NTFS文件权限变更引起的修改

git关于文件权限修改引起的冲突及忽略文件权限的办法

[讀書心得] SCM 軟體配置管理

書名: SCM 軟體配置管理  作者: 董越

這三天把這本書看完了，我大概 brief 一下每章的一點筆記就好，其實主要是書已經在身上，寫太多出來也沒有太大的必要 XD 大家有興趣再去看看書吧 :D (新年新希望難道沒有一年要看幾本書的目標嗎?! :P)

SCM 是 Software Configuration Management 的縮寫，書中翻為軟體設定管理，簡單的說就是對一個不斷演化的軟體資產做管理，主要有兩個方向，一是針對資產做管理以及儲存，二是適當的控制軟體的品質，像是關注於軟體的整合。

比較精確的定義要參考 IEEE-STD-610，或是你可以參考本書本書的ch01。

Ch02 基本的版本控制
* 即使只有一個人，也要做 SCM
* 防止版本覆蓋: 如果你仔細去細想，在多人開發軟體的時候，同一隻檔案被同時修改的機率非常高，因此防止檔案被別人覆蓋，是很重要的議題。
當然，不同的版本控制工具各有不同的處理方式，第一種是串列的方法，類似我們寫程式處理的 quene 啦，就是當有人要拿檔案去修改，該檔案就會被 lock 住，但是這雖然是一種方法，可是對開發效率來說是偏低的，因為如果檔案一直 lock 住，表示其它的開發人員只能乾等。這種防止覆蓋的方法的版本控制工具的一個例子是 Visual SourceSafe (縮寫 VSS，微軟出的古老版版本控制工具)。

第二種方法是平行，平行的處理手法解決了串列的問題，就是允許多人同時修改同一個地方，在做合併時，工具會判斷什麼時候需要合併，合併哪些東西，大部份情況是可以自動合併的 (像 git 的 auto-merge)，不能的時候就會叫你人工合併 (類似 conflict)。這類的版控工具，像是耳熟的 Subversion(SVN), GIT, ClearCase(CC, 同時支援串列跟平行的方法，是 IBM Rational 出品的商用軟體設定管理工具)。

書本有列一些市面上的版控系統，很多我也沒聽過 XD，但是後面幾個章節主要都是拿 svn, git, ClearCase 來比較，有 ClearCase 的原因我想大概是因為書中有提到他的市佔率蠻高的，老實說我不知道台灣有哪些公司有用到..?! 知道的朋友可以幫忙舉例一下 XD

不同的工具做類似事情的行話不太相同，像是:
* SVN 用 check out, commit, update...etc
* git 用 pull, fetch, merge, add, commit, push..etc
* ClearCase 用 check out, check in... 恩..ClearCase 我覺得比較複雜一點，但是我沒機會接觸到所以沒有特別去記，看看就過去了... 。

假設企業要導入 SCM，也要有人出來處理工具的選擇, 教育訓練, 制定開發流程等等。這也是 SCM Engineer 的工作之一~ 類似的職稱有 CM (簡稱配管), 或是設定經理 (Configuration Manager)。 一樣.. 我也不知道台灣有沒有這樣的缺 ?!  SCM Engineer 我是沒聽過耶 =="(我果然是井底的青蛙)...


Ch03 當代的版本控制方法
* 變更集合的概念 (或是變更套件  change set, change package)
* 小單位的修改就可以交付程式碼，盡量不累積
* 修改前先以拿到最新版的程式碼開始，或是反方向處理，在自己的工作區域修改後常常去更新 Repo 最新程式碼回來，在 git 是指 pull,  在 ClearCase 是指 Rebase。


Ch04 關注整體品質
* 這章主要在提整合。Intergration 主要的使命就是把產品的各部分合在一起，並且保障產品還是可以運作的情況，而不是每個模組, 單元都各自在特定的環境下可以運轉。因為每個地方都是正確的情況下，並不能確保整合在一起後就是正確的。

* 4.2 保障交付的品質: 關於這點，有幾個方向可以努力，一就是寫測試，單元測試與 TDD 是個很好的方法，再來是 Peer Review，或是 Code Inspection (現在很多 Peer Review 工具都有跟版本控制整合，像是 github 上就有幾套，只是大部份都要付費。在我任職過的公司 urAD 曾經對某專案做過 Code Review，還蠻有趣的，每個人都要針對同事發的 pull request 做 review)。還有 Pair Programming，目的也是加強程式品質。

上述的幾個方法，都是靠人來完成，當然也有方法，不是靠人來幫忙達到品質的把關，像是靜態程式分析 (Statis Program Analytics)，利用類似的工具發現程式碼的錯誤等等。畢竟有人就有可能有疏漏, 也有可能有犯錯的機會，所以利用一些工具來相輔相成幫助軟體的品質更好。


Ch05 從原始程式碼到執行中的程式碼
* 軟體的建構有兩種，全量建構 Full Build 以及增量建構 Incremental Build，主要指的是編譯連結的過程。 全量是從頭開始，重新編譯每隻檔案，比較耗時。增量主要是找有差異的重新建構，較快但有風險，相較之下比較沒這麼可靠。不過這個我體會不深，我寫的語言幾乎是不太需要編譯的 XDDD

Ch06 邁向持續整合
* 持續整合: 整合可以更頻繁，也就應該要更頻繁。如果能夠收到工程師的 commit 就開始進行整合是最好，通常也是會寫個 hook，當有人 commit 的時候就去跑 ci。
* 越大的專案，越能夠從持續整合中看到明顯的成效。 (但越大的專案要做持續整合也越難...)。
* CI 的工具有，像是有名的 Jenkins, 或是 CruiseControl (這個我就沒聽過了... )


Ch08 管理文件
* 軟體設定管理當然不只管軟體，也管文件。
* 軟體寫給機器看，文件寫給人看。
* 檔案的命名應該要加上版本號，另外也建議使用具有版本控制功能的文件管理工具。
* 不同文件可能會有保密的不同層級，應該要在文件附註這些資訊。


Ch09 
* 第九章都在講跟 bug 有關的，主要是也提到幾個 Defect Tracking System 缺陷追蹤系統，(Bug 的學名就叫做缺陷)。工具很多像是 Bugzilla, Redmine, Mantis, Trac, BugFree, ClearQuest (IBM Rational 出品的), JIRA。
JIRA, Redmine 我都用過，還蠻喜歡 JIRA，但是商用都是要付費的。
* 對於 bug 的描述一定要做到可以讓開發人員及 QA 可以做到複現，包含遇到的情況, 當時的作業環境。


Ch10
第十章在講遇到 Feature 時的處理方式，另外也提到 Scrum, FDD 等。

* Scrum 是敏捷開發的一種方法，用一種反覆運算, 增量為主的特點來開發軟體。 這裏的增量指的是 Enhancement 代表一些小小的功能請求，想在原有的程式加上一些功能。 (我也打算看一下 Scrum 的書，如果有推薦的書目也歡迎留言推薦給我，謝謝 ! :D )

* 除了可以用 Scrum 來管理這種一個一個的 Feature 之外，也可以用 FDD 也就是特性驅動開發 (Feature Drive Development) (wiki)，FDD 也是一種敏捷開發方法，我有找到一篇文章有興趣可以看看: David Ko的學習之旅 - Feature Driven Development 簡介。
(不過...  FDD 我比較少聽到 XD，大部份聽到 Scrum 比較多)

FDD 對於 Feature 的週期是兩週內完成，Scrum 的週期單位是用一個 Sprint (衝刺) 來算的，通常是 15-30 天，長度由開發團隊決定。

* 在瀑布模型下管理 Feature，要注意一旦決定要執行的計畫就不要去更改他了。(瀑布下要減少變更, 變更是不能夠隨意的發生，但不是指完全不行)

其實我覺得增加 Feature 在大型專案上比較麻煩，因為要往上通報，由主要 Leader 決定開發這個 Feature 的成本是否有意義，因為會影響時程, 開發人力，實際對 user 的方便性跟效益是否是值得的? 會不會引發後續的其他 issue 跟 maintain 時程, 以及相對應的測試 code 都要修改。

* 書中有提到可以成立變更控制委員會 (Change Control Board, CCB)，由一群人來決定是否要執行某個 Feature(我個人覺得有這種會議如果遇到很麻煩的 Feature 應該很容易開的沒完沒了 XDD )。

* Feature 的處理流程，應該要依照 Feature 的程度而有所劃分，並不是所有的 Feature 都要經過嚴格的管理。


CH11
11章在講學院派對 SCM 的理論。讀起來比較悶，感覺很像在唸考試的東西 XD 其實主要在講 CMMI 啦

* SCM 主要由四大部分組成:
1. 設定識別 (Configuration Identification, CI)
2. 設定控制 (Configuration Control)
3. 設定報告狀態 (C... Status Report)
4. 設定稽核 (C.... Audit)


後面章節的我就先不寫了，但都是在講 SCM 在實際場景的舉例，嘻! 有興趣知道可以買回家看看 :) 總之我是覺得，看這種書很快樂 XD 雖然實際上在工作不一定都能用到或是親生經歷，但是知道有什麼方法就夠了(工作與團隊之間，不同階段有不同挑戰)。

Rails Girls Weekly - JavaScript Basic For 6 Weeks（4/6)

昨天本來要發文，但是想說早上還要去參加 phpconf 2015 所以就早早睡了 :P

week4 講了基礎的 array, object 怎麼定義，還有 JSON，雖然講到 JSON 有點難了..sorry。
因為加了一小時講一點怎麼 commit 到 github，所以昨天有兩個 slide，只是最後 live demo 的時候沒有成功，不知道網路還是 github 怎麼了，有點可惜就是.. 下次我還是不要嘗試做這種 live demo 的事好了 QQ

老實說簡報都很基本，但是還是要看個人的接受程度，也有有些人會覺得很難，只是有些事情，就算當下的聽眾不能接受，我還是必須說一下，主要是因為這些都是"定義"，該描述出來的事情還是得說一下...。

git 反悔 commit，想要 rollback 恢復回到上一次的 commit

最近在工作上偶爾需要這個功能...，就是一直去 merge 別人的 branch，結果上一次 merge 的結果是有問題的，就會想要還原之前的版本，模擬的情境像這樣 (圖中的 SHA1 都是假造):

假設我有一個 branch 叫 winwu，這是我每次 commit 倒數幾個的歷程:

由於最後一次 commit (紅色那顆 ew3354) 其實是有問題的，所以我希望退回到 2Tefw88 那個 commit:

指令是:
git reset --hard 2Tefw88
git push origin winwu --force

簡化的表達方式是:
1. 首先 reset -hard 先“強制”回到某次 commit

git reset --hard 要 Rollback 的 commit SHA1

(有 --hard 也有 --soft，用法我沒有提到，可以自己去查查看 :P)

2. 接著重新 push 到你想要 push 的 branch，記住一定要有 force，否則 commit 不上去哦...

git push origin BRANCH 名稱 --force

參考文章:
Git 版本控制：利用 git reset 恢復檔案、暫存狀態、commit 訊息 - appleboy
http://stackoverflow.com/questions/927358/how-do-you-undo-the-last-commit
http://git-scm.com/docs/git-reset

git commit 時用 vi 編輯儲存時出現 Error...

不知道為什麼我的 Mac 在操作 git 時，打 commit 後 :wq (儲存離開)，會出現這樣的 Error:

➜  erp git:(master) git tag -a v1.1.1
error: There was a problem with the editor 'vi'.
Please supply the message using either -m or -F option.

這個 Error 很慘，表示我剛剛打的 commit 都不見了，所以也沒辦法有下一步 (push) 的動作。

在網路上有找到一個很奇怪的解法，要我把 git  預設使用的編輯器的 bin 路徑改掉，只要下這樣的 command 就可以正常 git comment:

➜  erp git:(master) git config --global core.editor /usr/bin/vim

很神奇... 如果有人知道為什麼請告訴我 TT。

解決 Fatal: Unable to create '.... /.git/index.lock': File exists. 錯誤

git commit 時一直出現 index.lock 的狀況，導致檔案無法加入 commit 的項目：

解法就是砍掉 .lock

rm -f ./.git/index.lock

就可以 commit，不知道有無更好的解法 :)

Reference

git clean 清除不需要加入版本控制的資料或是檔案夾

* 本篇要感謝教我這個小技的同事 Isac

因為工作的需要，我常常需要在一個 repository 不斷的嘗試一些新的 extension 或是 plugin (白話一點就是會一直安裝新的東西進 repo)，以至於常常需要下 git reset --hard ，還原到 commit 之前的版本，但是新增的檔案還是必須自己一個一個坎，這時候就可以下 git clean -f -d 來把不需要的檔案都清掉。

git clean -f -d

-f : force 強迫
-d : 資料夾



如果你只有下 git clean -f 那麼只會把不需要的檔案的刪掉，但是如果是資料夾可能刪不掉，因此需要再帶個 -d ，當然如果沒有資料夾的話就不需要 -d 了。

解決fatal: Not a git repository (or any of the parent directories): .git錯誤

有一次我在開branch的時候:

$ git checkout -b winwu/dev

發生了這個錯誤：
fatal: Not a git repository (or any of the parent directories): .git
不過,起因不是重點,因為就算我今天不是開branch,也有可能發生這個錯誤～

這個錯誤是在告訴你,你所在的目錄,並不是一個git的repository,換句話說,其實就是git在你這個目錄下找不到.git這個目錄,沒有這個目錄,有很多事很難再往下做,因此解決方法就是下git init,git init就是創造一個空的git repo或是重新初始化一個git repo。

$ git init

Reinitialized existing Git repository in h:/your_docs/your_web/.git

下了git init就會重新初始化這個git repo.

參考：git-init(1) Manual Page

最近認識的新工具: bitbucket

[此圖截自:https://bitbucket.org/]

最近因緣際會下認識了這個好工具叫做Bitbucket
其實他跟Github非常的相似，但5人以上團隊開發是要收費的。

不過我非常喜歡裡面的介面，自從看過JIRA介面之後才知道Atlassian這間公司，產品實在是很優秀，bitbucket理面的管理方式跟設定也很容易上手，是github的另一種選擇。

有興趣的話馬上註冊一下吧!
註冊方式除了可以直接註冊之外，也可以使用g+,  facebook, twitter跟github，可以說是非常親民且容易上手，不過若跟我一樣使用github直接註冊的話，記得以後要git clone一個專案之前先換密碼，因為在git clone的過程很有可能出現request URL returned error，到時候只需要更新bitbucket帳號的密碼就可以了 ，參考。

[此圖截自:https://bitbucket.org/]
這是我的bitbucket專頁，呵呵，註冊後馬上開了兩個repo，另外repo也可以跟JIRA做結合。

如果不清楚怎麼git流程，Bitbucket 101  也有非常詳盡的教學~
對於所有的工具實在很難有個詳盡的解說，多用就是了。
Keep Coding!

建立github.io專頁

最近看到好多人都有這樣的網址:

Http://[username].github.io/[repo name]

上網搜了一下，原來這是github提供的一種功能，如果你的Repositories有html頁面，可以利用github.io，轉換成html頁面，至於怎麼轉換，其實就是另開一個叫做gh-pages的branch，而不只是在github上看code。恩..不過它到底能做多少事情，我並沒有仔細研究。

P.S:自從會了這個東西我對git的敬畏程度又大加分了!><

• 情境一: 以前的Repository也可以匯出成github.io頁面
  手動建立的網頁(以前就開過的Repository)，只要在該repo上，開gh-pages的branch，內容同 master (不是開了就沒事xd), git push上去即可。
  
  Ex:http://winwu.github.io/fitness_80_practice/
       https://github.com/winwu/fitness_80_practice   
      這個範例是我前陣子的一個臨摹練習，原本的repo只有涵蓋index.html,js/css等等
      可以看看該repo的branch差異。
  
  走情境一方法的民眾可以參考這頁(Creating Project Pages manually)
  我是用上頁方法試出來的。

• 情境二: 為了開github.io而開新的Repository
  
  這種方法就是官網help頁面上面寫的Automatic Generator，也就是自動幫你產生好html頁面，走情境二方法的民眾可以看看這一頁(Creating Pages with the automatic generator)
  
  我只需要做:
  1. 在自己的github頁面，開新的repo，並且設定該repo的setting為Automatic Generator，接下來就是ㄧ連串奇妙的事情...
  2. 選樣版(Layouts)
  3. publish 發佈他...
  4. 我是發佈之後，在git clone下來修改html，然後再git push。
  
  Ex: http://winwu.github.io/resume/ 
  (<--這個UI很明顯的我是用github上面有的樣板來套用xd)

參考:
http://pages.github.com/
如何在 GitHub 建立个人主页和项目演示页面

git 的 cherry-pick

不是很確定文，只是隨手紀錄一下.... ，
可以忽略此篇文章，若有寫錯煩請糾正我一下，感謝!

cherry-pick 的定義是:Apply the changes introduced by some existing commits 

或者說...只合併指定的 commit
可以選擇某一個branch(分支)的一個或好幾個commit(s)操作
或者說...針對已經存在的commit 進行再次提交

講白話一點就是比方說我想要merge某些特定的commits從一個branch到另外一的branch，會這樣做是因為我希望只有某些特定修改的項目要merge，而剩下的就留在原來的地方，可能是我不需要上那個功能等等。


假設有兩個branch(staging, development)
在沒有做任何修改是這樣 :


A-B  staging
       \
        C-D-E-F-G  development


然後我新增了兩次 commit
分別是 H 跟  I 到 development 環境，就會變成:

A-B  staging
       \
        C-D-E-F-G-H-I  development


接下來可能因為專案的需要我必須只上H,跟I到staging的branch
其他的部分留在development，這時可以用cherry-pick
cherry是櫻桃的意思
這時候的櫻桃就是指 H,跟 I 了 ，把他pick起來送到staging這個branch

首先先切換到staging:
$ git checkout staging

然後cherry-pick H,跟I :
$ git cherry-pick H
$ git cherry-pick I
如果當初推的順序是先H再I，cherry-pick也要照這個順序
cherry-pick的行為有點類似merge

然後就可以push了

如果是使用cherry-pick 後不用 commit
因為對cherry -pick來說就是一次新的commit

但若使用cherry-pick -n(一次合併好幾個) 後要重新 commit



希望我有機會實作到這個部分再來寫更多的筆記。

參考:
Git 初學筆記- 指令操作教學| Tsung's Blog
Cherry-Picking specific commits from another branch

自己常用git指令與流程

(這篇是我自己習慣的流程，可忽略我這篇><)

雖然網路上有太多太多介紹git使用方式的文章，

可是如果沒有擁有環境可以實做，看再多我還是會忘記。

所以我目前先打算記下工作上有再用的指令...

其實我平常在用的指令也是不多，因為我也很少動到那些code，

只是說我也不敢為了做git的練習大玩公司的環境，

這樣簡直是拿工作開玩笑，所以找個保險的方法，因此記錄了這一篇，

當然我也可以不必大費周章做這件事情，只是說有時候一點無心的小動作，

很有可能造成很大的bug或是整個團隊的困擾，因此我要盡量避免這種情況。

note:

說到這個我突然想到不久前我用git練習切換branch把自己整個local給搞砸了..

這件事情讓我學到git是個非常大的學問...，有時候自己在github開一個小專案練習用根本沒遇過這種問題。

目前的心法是:

改了東西而且還有在自己的local存檔過，就不要再拉code(git pull)，
除非還原(checkout)或丟到垃圾桶，
所以開始作業之前先把code都下來到自己的local(git pull && git pull)，

如果先改code再拉code，很容易發生衝突，
一但有衝突就很麻煩，表示我又要爬文，或是麻煩資深前輩了..

改了一個檔想要還原怎麼還原?

git checkout /home/路徑... /myfile.副檔名

(簡單來說就是 git checkout 檔案路徑)

  

改好一個檔之後先在自己的Local做測試，若測試無問題後，準備要push之前先用:

git status

確認是否修改了哪些檔案

# On branch 你目前的branch名稱

# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   你修改過的檔名

#no changes added to commit (use "git add" and/or "git commit -a")

另外想知道修改了一個檔案的哪些地方可再下

git diff

可得知修改前與修改後的差異

確認無誤後要將檔案add以及commit到git:

git commit -am '這裡寫comment內容，可以是修了哪個bug..,..,優化什麼地方之類的comment'

(-am是比較方便的寫法，因為要add再commit，所以直接寫-am)

接下來就是git push 

git push後面的設定依專案需要，看個人。

等更新後，自行測試後回報git log, commit號碼(應該是SHA吧!?)給上層或是回覆在Bug tracking system之類的。

git基本流程筆記

首先先在自己的github新增一個Repository

開git bash:
簡單說明整個流程就是，從github下載一個repo到自己的本機，然後新增幾個檔案，然後commit，在push上去。

user@USER-PC /d
$ git clone https://github.com/winwu/fitness_80_practice.git
把剛剛新建立的repo 克隆下來

Cloning into 'fitness_80_practice'...
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
Unpacking objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)


(=====手動複製要加入的檔案到/d/fitness_80_practice/=======)

user@USER-PC /d
$ cd fitness_80_practice/

user@USER-PC /d/fitness_80_practice (master)
$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       SOURCE/
#       index.html
nothing added to commit but untracked files present (use "git add" to track)

user@USER-PC /d/fitness_80_practice (master)
$ git add .
warning: LF will be replaced by CRLF in SOURCE/jquery.min.js.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in SOURCE/jquery.scrollorama.js.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in index.html.
The file will have its original line endings in your working directory.

user@USER-PC /d/fitness_80_practice (master)
$ git add .

user@USER-PC /d/fitness_80_practice (master)
$ git commit -m "add new file"
[master 9bc5274] add new file
warning: LF will be replaced by CRLF in SOURCE/jquery.min.js.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in SOURCE/jquery.scrollorama.js.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in index.html.
The file will have its original line endings in your working directory.
 15 files changed, 994 insertions(+)

 create mode 100644 SOURCE/sweet80.png
 create mode 100644 index.html

user@USER-PC /d/fitness_80_practice (master)
$ git push
warning: push.default is unset; its implicit value is changing in
Git 2.0 from 'matching' to 'upstream'. To squelch this message
and maintain the current behavior after the default changes, use:

  git config --global push.default matching

To squelch this message and adopt the new behavior now, use:

  git config --global push.default upstream

See 'git help config' and search for 'push.default' for further information.

Username for 'https://github.com':
Password for 'https://winwu@github.com':
To https://github.com/winwu/fitness_80_practice.git
   ac2b662..9bc5274  master -> master

如何刪除自己github上面的Repository

做個紀錄，以免下次忘記怎麼刪，因為有些練習怎麼用git的repo必須刪掉阿...
不過我怎麼覺得這似乎是個很危險的動作(所以沒什麼問題的話盡量不要亂刪)，我當初以為刪掉一個repo應該沒有什麼，應該會很好找到機關把他刪掉，殊不知我找了幾分鐘有..

首先先到自己想要刪掉的那個repo頁面，找到右邊有個Settings按鈕，按下去就對了

然後按下setting後會看到下面這一頁，先把滑鼠滾到下方紅紅的區域。

在紅色的這個Danger Zone的地方有個"Delete this repository"的按鈕，
按下去會出現警告視窗。

警告視窗詢問是否要刪掉，並且你要填入一些資訊

填入要刪除的repo名子，再按下下方I understand the.... 就成功了。

在fedora安裝git

在fedora安裝git : (必須是root身分)
yum install git-core

安裝過程會一直出現問你y/n (yes or not)，y下去就是了
安裝完成後會出現complete!