開發常用的 Git 與 GitHub 操作

先前有遇過設計部門同事,送commit 與 PR 但不熟 git 與 github 的操作,所以寫這篇

開發常用的指令

在 master branch 用 git pull 讓local 開發環境的 master 與 Remote的同步
 
然後 git chekcout -b [new branch name] 來新增一條 branch 做開發
 
開發到一半,想切換branch,就用 git checkout [branch name] 切換到另一條已存在的branch
 
若是某個branch已經merge了,你想砍掉local的branch,可以用 git branch -D [branch name]
 
若是想要砍掉remote的branch,則用 git push origin :[branch name]

查看過去的commits

傳統 Git 會用 git log ,但是我較偏好用 git lg,讓訊息更簡潔
 
git lg 設定:在 terminal 裡輸入

git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

可以用 git lg 看全部的commit,然後按 q 跳出,或是用 git lg -[數字]

例如:想看最新4條commit就用 git commit -4

把修改的內容推一條新commit

送出一條commit的操作步驟

  1. git status 查看哪些檔案還沒被放入commit
  2. git add [單一檔案的檔案路徑] or git add . 把所有修改過的檔案都加到同一條commit
  3. 送出commit的方式有兩種: git commit or git commit -m “[commit message]”

若只用 git commit 會進入vim的編輯模式
 
在vim的編輯模式裡,要先按 i 才能輸入文字,等打完commit內容後,再按 :wq 儲存後退出 
 
若是用 git commit -m 則不會進入 vim 的編輯模式

把修改的內容加入前一條commit

有的時候,我只想改一個小地方,不想每修改一點就送一條commit,那麼我就把修改的內容加到前一條commit,透過 git commit —amend
 
 若是不想進入 vim 編輯commit message,則可以用 git commit —amend --no-edit

把其他branch的commit加進來

流程

  1. git checkout [另一條branch]
  2. git lg 查看commit代碼
  3. git checkout [開發中的commit]
  4. git cherry-pick [commit代碼]

每天都讓開發的branch 與 master 同步

一條branch如果開發太久沒跟master 同步,我自己的經驗是修 git conflict 修到死。
 
所以我每天都會去注意master brach 有沒有推commit,如果有則操作流程:

  1. git chekcout master
  2. git pull
  3. git chekcout [開發branch]
  4. git rebase master

如此一來就能讓開發branch 與master 同步

Git conflict

rebase master 後,有時會有 conflict,解 conflict 的操作步驟

  1. git rebase
  2. 遇到 conflict ,停在某條commit
  3. git diff 查看哪個檔案 conflict,然後去修它
  4. 所有東西都修完後, git add .
  5. git rebase --continue

開發到一半,被叫去修別的bug

我自己是習慣

  1. git add .
  2. 然後 git commit -m “開發進度、目前的盲點” 然後切去master 開新branch來修bug
  3. 修完bug 後,回來開發中的branch用 git reset HEAD^

切換branch時我都會習慣先 git lg -10 看看該branch的開發狀況,由於我們家有 commit 用英文的習慣,看到commit 用中文寫就會知道要記得 git reset HEAD^

GitHib常用到的操作

送PR (Pull Request)

開發完後,要送PR給ci 跑測試,並deploy branch 線上測

  • 要送PR時,透過 git push origin [branch name] 推上去
  • 然後去Github的專案上面點選 Compare & pull request

有時候 Remote 的 commits 與 local 的commits 不一致,這時就要 force push,透過git push origin -f [branch name] 就能強制push上去

Merge PR

GitHub提供三種merge方式

  • Create a merge commit
  • Squash and merge
  • Rebase and merge

這三種merge方式,我自己的習慣

  • commit數量大於三,一律用 Create a merge commit
  • 如果修改的內容很簡單,只有一兩個commit,就用 Rebase and merge
  • 如果一隻PR經歷了千辛萬苦生出一條commit,我會用 Rebase and merge ,讓master branch 的commit 可以看到原本PR的討論串

blame & History

有時候,我們要查出問題的code是誰寫的,就用 Blame

若想看某支檔案過去commit的歷史,也可以用 History
 
 當然也能在terminal 裡用指令看過去相關的commit, git lg -[想看幾筆資料] [檔案路徑]

搜尋欄

找open source 的資料滿好用的,有時候開發有bug解不出來,Google 或 Stackoverflow 都找不到
 
 我會習慣去相關open source 的 Github,在搜尋欄下關鍵字,找issue、找wiki、看source code,然後一不小心就把bug解了

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.