這篇寫的最好了
都已經出書了

github建立repo的方式是基於git init還是git init --bare?
如果照git init --bare只記錄版本來說
我從github clone下來 應該不會有工作目錄
所以github應該是採用git init對嗎?

GitHub 上的 repos 使用的是 純版本庫 (bare)

what's the difference between github repository and git bare repository?

clone 可以將遠端 repo 複製到本地
預設會產生一般的 repo (包含工作目錄)

git clone

不過也可以選擇 bare 產生純版本庫

git clone --bare

所以 clone 下來的目錄，其實和遠端的版本庫，是不是使用 bare 產生的無關

什麼情形下會只要記錄版本 而不用工作目錄?
小弟百思不解
我要在某主機端上掛程式 也要做版控
這樣當然是採用git init才會正確
不然主機沒辦法跑程式

沒錯，純版本庫是用於遠端的版控機
不能在上面新增或修改檔案
只讓大家同步程式

遠端的共用版本庫，建議使用純版本庫
不過想使用一般版本庫也可以
但需要改一些設定
比較不建議

為什麼大多數的人都建議遠端要用git init --bare來建立
其實跟上一題感覺很像@@

應該是使用正規的做法比較沒有問題

我有試了一下，推一般的版本庫

不過不給我過 （╯‵□′）╯︵┴─┴

查了一下，改設定檔可以解決
這裡我就不往下測了

Git push error '[remote rejected] master -> master (branch is currently checked out)'

就是好奇為啥可以記錄版本而沒有程式

其實工作目錄和程式無關
commit 內本身就有程式紀錄了
純版本庫也是可以使用 git show 查看程式紀錄

2020/07/15 更新

大大這樣的意思是不是就代表 那台版控機就是git server
跟github功能一樣
所以並不會在那台主機上跑專案
而是在另一台主機上跑專案
所以在正常的開發流程下會有至少三台機器以上在運作?
一台local
一台git server做版控
一台跑專案

這是一個概念，沒有限定要用幾台機器

以上圖為例
員工 A、B、C 的電腦裡有各自的 Git 版本
記錄了今天完成的項目

該如何合併三人的程式呢?

大家下班前會將自己的部分 push 到遠端
隔天上班在 pull 下來
這樣大家的程式就合併完成了
這就是 Git 的操作概念

遠端究竟要用純版本庫還是一般版本庫?

其實都可以
程式的世界沒有標準答案
只要能達到目的
過程用什麼樣的技術其實不太重要

總共需要幾台機器呢?

三台或四台

四台:
A、B、C 員工各一台
加上遠端的一台

三台:
A、B、C 員工各一台
遠端設在員工A電腦上 (和員工A的開發庫分開)

遠端不一定要獨立機器
上面所說的只是概念
遠端可以存在於各種形式

GitHub、FTP、某人的電腦開放外連

大大指的正規做法應該是指裸儲存庫的方式
主要是我不懂裸儲存庫的好處是什麼
他做得到的非裸儲存庫也做得到
除了需要多設定一些東西

我後來發現不能推不是設定的問題
原因是遠端我 checkout 了 master 分支
本地就不能推同名的分支
避免覆蓋到遠端的工作目錄

repo 和 bare repo 其實就差在工作目錄而已
把他們分開，應該是為了避免 checkout 衝突的問題
也方便解釋 遠端和本地 的概念

git是否能夠取代ftp?

不一樣的東西

目前小弟我有嘗試出這種方法
以下是步驟
1.在遠端(主機)建立一個儲存庫(非裸)
2.本地端clone下來
3.本地端修好程式push上去
4.遠端checkout 新版本(如此便會更改工作目錄的程式)
這樣既可以記錄又可以做到遠端開發的感覺
不知道這樣的流程是否正確

一般不會特別到遠端做 checkout 的動作
遠端只用於紀錄

當然你習慣這樣使用也是可以拉 ╰ ( ´ ▽ ` ) ╯

2020/07/16 更新

但是我在意的點是在專案機和版本機是不是分開的?
為什麼要分開? 有什麼好處嗎?

都可以
我自己會將版控放在 GitHub 或 NAS 上
如果機器不夠和專案放一起也可以

分開方便管理，Server 和 Git 的權限可以開放給不同的人

至於我為什麼會問git能不能取代ftp
就是因為我提到目前的開發流程有關
我push到遠端主機(專案機,版本機同一台)
可以同時更新專案(ftp的功能-檔案傳輸)也可以記錄版本
因為我有寫個post-receive的hook
所以我也不用特地去遠端再checkout
只要push到遠端就會更新程式

這個需求比較適合使用 CI/CD 持續整合

如果不想複雜化
你目前的做法也是不錯的