分享 Trac 與 Git 的使用心得 @ 資拓宏宇

剛到前 Yahoo! 同事 Anderson 公司、資拓宏宇分享了「Trac 與 Git 的使用心得」。

Git - Social Coding System

大部分的時間都在講 Git，講了以下主題：

• Git 是與 SVN、Perforce 完全不同的分散式架構。
• Git 最強的功能 - Branch 協助你自己的分工。
• 分散的集中管理 - Git Central Repository 多人開發團隊。
• 遠端 Branch - 協助 Code Review 或小組工作。
• 將 Open Source 專案用一個指令掛進你的專案控管 - Submodule。
• Git 工具與應用 @ miiiCasa
• 實現 Social Coding 的平台 - Github

發言很踴躍，看得出來大家都對 Git 這個主題有興趣、也很贊同這樣的架構。

這裡要提 Git 給我的想像與精神，引用自己投影片的結語：

對我來說，Git 開放與易於擴散的概念實在太棒了
GitHub 更基於此建立起了社群與機制
唯有 Open、讓程式被看到、被使用、被批評，才有改進的動力
公司內建立能重複使用的函式庫、往往最後都沒人用
想一股腦地將自己及公司內可開放的...
規範、專案、工具往 Github 丟
期待各位也能成為 Social Coding 的一份子！

有人問了 Git 的規範

不過我們其實沒有去定義這一塊，就分享一下我很認同的 commit notes 的寫法：

它建議不要使用 git commit -m ""、應該多進入編輯器。
第一行寫少於 50 個字元的 Summary、空一行再寫詳盡的描述（描述每行不能超過 72 個字元）。
這樣做可以在很多呈現的地方帶來好處 (git shortlog, GitHub, git format-patch, git send-email...)。
另外還建議使用現在式 (Fix Bug) 而非過去式 (Fixed Bug)、主因是跟 git merge 或 git revert 產生的 log 一致。

Trac 在 miiiCasa 的應用

因為大多是抓內部 Wiki 的 Snapshot，就不方便把投影片放出來囉。

Trac 有先天上架構的不足（跨專案、權限控管不足）、加上近期更新緩慢...
雖然我們目前用得很滿意，但只要一扯到跟需讓非公司的人存取（例如 Bug）、更換為 Redmine 是遲早的事情。

另外我有特別點出 Wiki 系統不容易用於分享或討論，大家都還是習慣用 Email 。
特別講了 miiiCasa 利用 Google Group 做 Email 備份，即使是新人也可以觀看過去的分享。
適合放在 Wiki 的文章便可定義為以下幾種類型：

• 程式規範
• 內部教學文章
• Weekly Report

程式及團隊規範文件需嚴謹，分享的部份自由發揮吧！

另外來上課的同學們都來自不同專案與部門，
有相同的感嘆：同一個公司、但各自的系統不同、隨意亂長、沒辦法做累積。
這對軟體開發來說是一個很大的罩門。
還好現在 miiiCasa 沒太大，大家也可以產生相同的共識。
有夠好的新技術或系統也可以花時間轉移。 穩定的單一平台系統讓大家專注與累積是一件很重要的事。