Git submodule

有些時候,我們會需要幾個檔案和其他專案共用,而 iOS 的專案可以採取 CocoaPods / Carthage,但如果是要和其他語言共用的話該怎麼辦呢?

舉個例子,Server 和 Client 之間傳遞 Status Code,像是 code: 20000、20001、20002 之類的,收到 code 後要再做後續動作。

不過一份 Code 的定義散落在多個平台 / 專案之中,難免會有人雷的時候;不論是 client 記錯或是 server 回錯,而若是有個地方可以共同維護的話,便可以減少這種失誤。

所以就把那些文件(e.g .json)放到 repository 上,然後在你的專案之中:

git submodule add YourDocumentRepository.git

就會在你的專案資料夾中看到 clone 下來的結果,接著再將檔案拖拉至專案之中即可使用。

若要更新 submodule,則下

git submodule update

或是到 clone 下來的資料夾

git pull

像是如果懶得在每一個檔案都 import PodName,就直接弄成 Submodule 的方式來處理也行!

如我自己習慣的一些 Extension 就這麼弄。

Git LFS ( Large File Storage )

今天在更新 BlayPods 時,發現 Realm 的某個檔案(60.04 MB)超出了 GitHub 的上限(50.00 MB),所以無法順利地將檔案推上去 GitHub,而 Git 也自行 untracked 那個檔案,所以在 git status 上便失去了蹤影。

至於為什麼會將 Pods 的檔案全推到 GitHub 上呢?

而在 git push 的時候,有顯示解決的方法,便是今天的主題:

Git LFS

首先我們透過 brew 來安裝 git lfs

brew install git-lfs

接著繼續在 git 裡頭安裝

git lfs install

再來我們就來定義哪些檔案需要被 lfs track,像我這邊是這樣:

git lfs track 'Pods/Realm/core/librealmcore-ios.a'

然後可以透過指令來確認是否有被加入到 track 的名單

git lfs track

git status

現在就可以從 git status 之中再次看到剛剛沒推成功的檔案被 track 了!

git lfs track 的內容會被記錄到 .gitattributes 裡頭,所以也一併推上 GitHub 即可完成!

git push

這樣便可以在 GitHub 上處理單個檔案超過 50.00 MB 的問題,不過免費流量為 1GB / month。

 

Pods 到底需不需要放在 .gitignore?

若有使用 GitHub 所預設的 Swift .gitignore,你會發現在 CocoaPods 的部分寫著

# CocoaPods
#
# We recommend against adding the Pods directory to your .gitignore. However
# you should judge for yourself, the pros and cons are mentioned at:
# https://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control
#
# Pods/

用意如同字面上的意思,GitHub 所提供的預設會建議你上傳 Pods 的內容到 git server 上,

而我個人也認同這種做法,目前所想的原因如下:

  • 可以完整地打包套件當前狀態到 git 上,以避免套件有異動
  • 若你們有直接修改 Pods 裡頭的 Source code 的話,更加得上傳(不過完全不建議這麼做)
  • git clone 下來之後可以不用再 pod install 一次

不過也是有些壞處,如套件越多時,造成 git 上的專案肥大等。

但是像是 Carthage 的話,就會建議加入到 .gitignore,畢竟它的用意就是要去中心化,

若將自己 build 出來的套件放上去就和中心概念背道而馳了!

upgrade git

前言

git 最近被發現有重大的漏洞,以我們能做的事情就是更新自己的 git!

在 macOS 上更新

macOS 上,預設的 git 為 git version 2.15.1 (Apple Git-101)

所以我們需要先透過 brew 來安裝 git

首先,我們先來更新 brew,這點和 CocoaPods 類似,需要更新本機端的項目;

順道升級 brew 目前裡頭的項目。

brew update && brew upgrade

接著就透過 brew 來安裝 git

brew install git

最後再將 Symbolic link 處理一下就好了!

brew link --force git

現在我們確認一下 git 是否已經為新版本(git version 2.17.1)!

git --version

多個帳號的 SSH Config 設定

一般的情形下,我們不會太需要去做 config 檔案的設定,

因為其實不太需要建立太多組的 SSH key 來增加管理上的麻煩;

但隨著身份的增加(大多數是因為工作關係),

我們會需要用到其他組 SSH key 來連接 git server。

如果公司使用的 git server,是我原本就沒有使用的呢?

那就沒什麼差了。

就像是我第一份工作,公司所使用的 git server 為 AWS 的 CodeCommit,

而原先我根本就不用使用到那邊的服務,所以建立一組 SSH key 在 AWS 上使用也沒什麼衝突。

且 AWS 上的教學文件,會讓你在 ~/.ssh/config 之中,以 Host 作為區別;

所以它只會在 AWS 上使用你為了 AWS 所建立的 key。

但⋯最容易發生的情形就是:

公司也使用 Github 作為組織的 git server

通常我們會有一組自己私人的 Github 帳號,若公司不反對你使用私人帳號加入組織的話,

其實你也就沒什麼差了;

但大多數的情形是會給你一組(或是請你申請一組)公司信箱的 Github 帳號,

來維護 private git repository。

Public key

我們先來看看 ssh 的 public key 裡頭,帶了哪些資訊:

重點便是最後的 xpopchi@gmail.com

這把 key 會知道是和哪個信箱綁定在一起的,所以在 Github 上,

公司和私人的帳號便無法共用同一組 SSH key。

所以我們得替公司的信箱再建立一組 SSH key

建立的流程可以看 Github 上的文件,不過會需要在建立時,替它取不同的名稱:

e.g Archie_Apple.pub

個人的習慣是在後面加上公司的名稱來做區別。

它都會放置在 ~/.ssh/ 裡頭,我們需要透過編輯 ~/.ssh/config 的方式,

以及 git url 的調整,來做到使用不同的 key 連接同一個 git server。

~/.ssh/config 的設定方式

我們透過不同的 Host 命名方式,來定義裡頭要使用的哪一把 key 去做連結:

這邊可以看到,我在 Host 那邊區隔出 github.com-Applegithub.com

意思便代表著當 SSH 的 url,host 為 github.com-Apple 時,

會使用 Archie_Apple 這把 key;

而其他的 github 就照舊使用私人帳號的那把。

最後,使用的方式

在你原先進行的 url 之中,做一些調整:

git@github.com:ArchieR7/APNsPusher.git

這是使用私人帳號的方式,而若要使用 Archie_Apple的話:

git@github.com-Apple:ArchieR7/APNsPusher.git

這樣就能夠使用另一把 key 來進行動作了。

不過最好是在 ~/.ssh/config 之中補上 user.name 和 user.email,

否則之後再進行 commit 時,都會以預設的名稱和信箱作為 commit 的作者。