Git | 分支的合併
前言
這篇文章將會介紹分支的合併，以及它常見的分類。
分支合併 | Merge
雖然分支合併對於小團體來說，似乎是沒那麼重要的功能，因為它是同步進行不同功能開發時，兩位程式員才會使用到的功能。
快轉合併 | fast-forward
我們在建立分支的時候，最初的節點內容如果沒有繼續做更新，而是保持當初分出來的樣子，這種情況下的合併就稱為快轉合併，在歷史紀錄中，分支的內容會直接合併回原本的分支，成為一條線。
非快轉合併 | none fast-forward
當我們建立的分支有兩個以上時，這種情況下的合併稱為非快轉合併，這也是我們比較直覺所謂合併的定義，要注意兩個分支的內容不能互相衝突，當合併完成以後，分支會向拼圖合在一起的感覺。
因為沒有嘗試過，所以場景範例是我預期會有的畫面，非快轉合併是指同時進行兩個以上功能的開發，像是玩家 UI 介面的分支和遊戲角色移動的分支，當我們合併以後，遊戲畫面就同時有角色移動和 UI 介面的呈現。
後記
版本控制其實沒有我想像中的困難，應該說對於一位程式運作的情況下，版本控制幾乎用不到除了 Commit 以外的功能，因此接下來的文章我應該都不會有嘗試的機會，有錯誤歡迎協助我更正。
為什麼會看到廣告
106會員
247內容數
對設計師如何成長為設計師好奇嗎? 2020年九月，我進入大學學習當一位設計師，從開始到沉寂，再到重燃熱忱，我將在方格子紀錄我的成長歷程、理念、心情，分享我在這段旅程中所經歷的故事。
留言0
查看全部
你可能也想看
Google News 追蹤
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
改稿真的不是一件需要太多情緒的事，把錯的挑出來、改掉，就這麼簡單！很少有什麼「大錯」需要去爭執誰對誰錯。不過真的滿多時候鬼遮眼或是偶爾真的會發生某種「明明前一版是對的，這一版居然是錯的」的鬼故事，把問題找出來解決就好！
獨立遊戲開發，很多時是一個想法和熱情冒出來後，就叫人衝到電腦前想快點把成品弄完……就算做不了完整版，至少也想有個Demo。
既然想「快點」，那還要不要「花額外時間」去寫企劃書呢？
在處理這個問題之前，要先理解的是，這句話裡面至少有兩種情況。
其一：團隊裡只有一個企劃，所有事情都由一人主導
分支與合併 Branching and Merging[1] 。 這裡提供一個很有趣的說法， 就是理解「分支 Branching」最好的方式， 就是把它理解成「上下文 Context」。
Pair programming，譯為「結對編程」，是敏捷軟體開發的一種方式，由兩位軟體工程師同時開發一個程式，簡單來說，原本一個人可以完成的工作，找了兩個人來做，人力成本直接變成兩倍！
｜本篇報導同步刊登於 科技島
在大量運用 AI 人工智慧的時代，為何外商軟體公司仍積極運用結對編程進行
版本控制 (Version Control)，
是一種追蹤檔案被更改歷史的技術，
是團隊合作必備的工作實務[1]。
我在博士一二年級時期，
比較像是單打獨鬥，
與合作的學弟妹也是一對一溝通，
可以維持同步，把研究成果做出來。
然而，當我到博士三年級以後，
※ 需要做版本備份時：
git init：初始化此資料夾，由git 開始追蹤版本控制。
git add：將檔案加入到暫存區。
git commit：把暫存區的內容提交到儲存庫。
git status：查看目前所有檔案的狀態。
git log：查看過去所有commit的記錄。
※ 需要做修
※ 同步概念：
單純地「由上而下」執行程式碼，而且一次只執行一件事，也就是「按順序執行，一個動作結束才能切換到下一個」。缺點是你需要「等待」事情執行完畢，才能繼續往下走。
※ 非同步概念：
盡可能讓主要的執行程序不需要停下來等待，若遇到要等待的事情，就發起一個「非同步處理」，讓主程序繼續執行，
※ 簡短說明Git 和 Git Flow 是什麼？如何應用？
Git 是什麼？
Git是一個分散式版本控制軟體，能夠紀錄檔案的狀態變化，以及協調多個開發者之間的工作。它允許團隊成員協作編輯和管理項目的代碼庫，並且能夠追蹤文件的歷史變更、恢復到以前的版本、合併不同版本的代碼，以及解決代碼衝突等。
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
改稿真的不是一件需要太多情緒的事，把錯的挑出來、改掉，就這麼簡單！很少有什麼「大錯」需要去爭執誰對誰錯。不過真的滿多時候鬼遮眼或是偶爾真的會發生某種「明明前一版是對的，這一版居然是錯的」的鬼故事，把問題找出來解決就好！
獨立遊戲開發，很多時是一個想法和熱情冒出來後，就叫人衝到電腦前想快點把成品弄完……就算做不了完整版，至少也想有個Demo。
既然想「快點」，那還要不要「花額外時間」去寫企劃書呢？
在處理這個問題之前，要先理解的是，這句話裡面至少有兩種情況。
其一：團隊裡只有一個企劃，所有事情都由一人主導
分支與合併 Branching and Merging[1] 。 這裡提供一個很有趣的說法， 就是理解「分支 Branching」最好的方式， 就是把它理解成「上下文 Context」。
Pair programming，譯為「結對編程」，是敏捷軟體開發的一種方式，由兩位軟體工程師同時開發一個程式，簡單來說，原本一個人可以完成的工作，找了兩個人來做，人力成本直接變成兩倍！
｜本篇報導同步刊登於 科技島
在大量運用 AI 人工智慧的時代，為何外商軟體公司仍積極運用結對編程進行
版本控制 (Version Control)，
是一種追蹤檔案被更改歷史的技術，
是團隊合作必備的工作實務[1]。
我在博士一二年級時期，
比較像是單打獨鬥，
與合作的學弟妹也是一對一溝通，
可以維持同步，把研究成果做出來。
然而，當我到博士三年級以後，
※ 需要做版本備份時：
git init：初始化此資料夾，由git 開始追蹤版本控制。
git add：將檔案加入到暫存區。
git commit：把暫存區的內容提交到儲存庫。
git status：查看目前所有檔案的狀態。
git log：查看過去所有commit的記錄。
※ 需要做修
※ 同步概念：
單純地「由上而下」執行程式碼，而且一次只執行一件事，也就是「按順序執行，一個動作結束才能切換到下一個」。缺點是你需要「等待」事情執行完畢，才能繼續往下走。
※ 非同步概念：
盡可能讓主要的執行程序不需要停下來等待，若遇到要等待的事情，就發起一個「非同步處理」，讓主程序繼續執行，
※ 簡短說明Git 和 Git Flow 是什麼？如何應用？
Git 是什麼？
Git是一個分散式版本控制軟體，能夠紀錄檔案的狀態變化，以及協調多個開發者之間的工作。它允許團隊成員協作編輯和管理項目的代碼庫，並且能夠追蹤文件的歷史變更、恢復到以前的版本、合併不同版本的代碼，以及解決代碼衝突等。