Post
Ask Question

Source Control (4-9-3), Git - Merge in Concept

This is a series of articles related to Source Control or Version Control issues, from a stand-alone app, such as MS SourceSafe, to a Server app, such as MS TFS (Team Foundation Server), to web services such as GitHub, AWS, and MS Azure DevOps. We have tried to categorize this series of articles as Source Control or Version Control, but this site does not have these categories. So, we put the articles in the DevOps category, as explained in the Wiki:

DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality.[1] DevOps is complementary with Agile software development; several DevOps aspects came from the Agile methodology.

The structure of this article series will cover:

  • Stand Alone App:
    • MS Source Safe
  • Server App
    • MS TFS (Team Foundation Server)
  • Online (Cloud) Centralized Service:
    • MS Azure: DevOps
      • Boards
      • Repos
      • Pipelines
      • Test Plans
      • Artifacts
    • GitHub
    • AWS GitHub Enterprise
  • Distributed App:
    • Git

Because these are huge topics, I will not go step by step. Instead, each section will be relatively independent and will become a reading unit.

A - Introduction

We have discussed Merge for TFS in the article, Source Control (2-2), TFS --- Merge.  We also discuss a little bit about Git Merge in the article, Source Control (4.9), Git --- Merge: Fetch, Pull, Push and Sync. Now I will discuss more about Git Merge, 

  • In Server Side: 
    • MS DevOps
    • MS GitHub
    • GitLab
  • In Client Side:
    • in Visual Studio
    • by Git Prompt Command

I should emphases here, TFS Merge and Git Merge are quite different concept, while TFS is a server side centralized Software, client side interface, such as Visual Studio, is just a dummy interface, that is synchoronous with server, as a input/output interface at al, Git is a client side or distributed Software in client side, that is an independent software, it can be a indenpendent system working in client machine, the conversation to server, just push/pull the result to/from server to make client and server synchoronously.

In IDE, such as Visual Studio, you have to choose either using TFS or Git, choose:

Menu Bar => Tools => Options => Source Control => Plug-in Selections, got:

Git:

TFS:

Compared to TFS Merge, Git Merge has more choices, such as from Merge Strategies in Git - GeeksforGeeks, that

  • Fast Forward
  • Recursive
  • Ours
  • Octopus
  • Resolve
  • Subtree

But we will not discuss that kind of complex types, we will only discuss the basic types, say, most often happening in different Source Control Servers, 

  • Merge in Servers
    • Merge in DevOps
      • Merge (no fast forward)
      • Squash Merge
      • Rebase Merge
      • Semi-Linear Merge
    • Merge in GitHub
      • Merge (no fast forward)
      • Squash Merge
      • Rebase Merge
    • Merge in GitLab
      • Merge (no fast forward)
      • Squash Merge
  • Merge in Client
    • Merge in Visual Studio
      • Merge (no fast forward)
      • Squash Merge
      • Rebase Merge
    • Merge in Git --- all types of merges, but we only discuss
      • Merge (no fast forward)
        • Merge Fast Forward
      • Squash Merge
      • Rebase Merge
      • Semi-Linear Merge

We will discuss the contents in this article

  • A - Introduction
  • B - Test Program
  • C - Merge (No Fast Forward)
  • D - Fast Forward Merge
  • E - Squash Merge
  • F - Rebase Merge
  • G - Semi-LInear Merge
  • H - Summary --- Merge In Concept

B - Test Program

Master Branch:

Feature Branch:

They all are starting from commit 577fd5aa at 0/10/2023 12:18:31, as

We follow the pattern:

C - Merge (No Fast Forward)

A standard merge will take each commit in the branch being merged and add them to the top of the base branch based on the timestamp of when they were created.

It will also create a merge commit, a special type of “empty” commit that indicates when the merge occurred

Graph Demo:

Git CLI Code:

Merged:

Note:

The changes in feature branch will be added on the top of the Base Branch. The last commit of base branch, "save 5", is made on 07/24/2023 6:33:31 PM, while the first commit of the feature branch. "save A", is made on 07/24/2023 6:30:32 PM.  All commits from feature branch will be on the top of the base branch,.

Advantages:

  • Most descriptive and verbose history, tells us exactly when things happened, helps give the best context about code changes
  • Allows us to see a graph of when branches were made using git log --oneline --graph or git reglog which can help understanding why changes were made and when
  • Allows us to see each commit that made up the eventual merged changes, no loss of granularity

Disadvantages:

  • Merge commits are often seen as messy as they are empty and only really there for historical reasons. Can be especially confusing if you are trying to revert a set of changes.
  • Can end up having a complex graph of previous branches that’s more difficult to read

More Graph Demo:

D - Fast Forward Merge

If we change our example so no new commits were made to the base branch since our branch was created, Git can do something called a “Fast Forward Merge”. This is the same as a Merge but does not create a merge commit.

This is as if you made the commits directly on the base branch. The idea is because no changes were made to the base branch there’s no need to capture a branch had occurred.

Graph Demo:

Prepare data:

We use the same feature branch given in the Test Program, while we change the base or master branch to fit the requriment of the Fast Forward Merge:

from Original festure branch:

Get rid of new commited: "save 1" to "save 5", we have the original commit 577fd5aa at 06/10/2023 12:18 31 PM

Git CLI Code:

Git CheckOut TargetBranch
Git Merge --ff-one SourceBranch

Merged:

Advantages:

  • Vary fast because there is no commit.
  • Keeps a very clean commit history
  • Allows us to see each commit that made up the eventual merged changes, no loss of granularity

Disadvantages:

  • Can only be done when the base branch hasn’t had any new commits, a rarity in a shared repository
  • Can be seen as a inaccurate view of history as it hasn’t captured that a branch was created, or when it was merged

More Graph Demo:

E - Squash Merge:

Squash takes all the commits in the branch (A,B,C) and melds them into 1 commit. That commit is then added to the history, but none of the commits that made up the branch are preserved

Graph Demo:

Git CLI Code:

Git CheckOut TargetBranch
Git Merge --squash SourceBranch

Merged:

Advantages:

  • Keeps a very clean commit history
  • Can look at a single commit to see a full piece of work, rather than shifting through multiple commits in the log

Disadvantages:

  • Lost of granularity, any useful detail in those commits that made up the branch is lost, as are any interesting decisions, changes in logic etc captured during the development process.

More Graph Demo:

F - Rebase Merge:

A rebase and merge will take where the branch was created and move that point to the last commit into the base branch, then reapply the commits on top of those changes.

This is like a fast forward merge, but works when changes have been made into the base branch in the mean while

Graph Demo:

Git CLI Code:

Git CheckOut TargetBranch
Git Rebase SourceBranch

Merged: Rebase test3 on master (VS command):

Advantages:

  • Keeps a very clean commit history
  • Keeps the individual commit granularity

Disadvantages:

  • Can cause frustration as, if someone was to commit to the base branch against before you get to merge, you have to rebase again
  • Can be seen as a inaccurate view of history as it hasn’t captured that a branch was created, or when it was merged
  • Difficult to see which commits relate to which PR / branch

More Graph Demo:

G - Semi-LInear Merge:

Graph Demo:

It is a mix of rebase and a merge. First, the commits in the pull request are rebasedon top of the master branch.  Then those rebased pull requests are merged into master branch.

Merged:

H - Summary --- Merge in Concept

Why Branches in Source Control:

When we use code source control, such as MS SourceSafe, TFS, DevOps, GitHub, GutLab, Bitbucket, we usually make one or more branches. The reason, only reason, for it is when we have a team work on the code toghther, team members may work on the same piece of code and make conflicts to each other.  The seperated branches are possible for different team members to work on the same project, the same piece of code at the same time, but independently, without any conflicting with others.

Why Merge:

After eahc team member worked on the independent piece of code, they need to move the developed, changed code, back to the, say, masteer or main branch, to have one uniformed project. This is what the MERGE does.

Merge Types:

For the purpose to make the merge efficiently and organized, there are several types of merges:

  • Fast Merge
  • Merge without Fast Merge
  • Squash Merge
  • Rebase Merge
  • Semi-Linear Merge

We realize that Fast Merge and Rebase Merge are definitely the LInear Merge. Basically, they are not really a merge, they just move the HEAD to a appropriate position to finish the "MERGE", like these:

Fast Merge:

Rebase Merge:

Probably, we can put Sqush Merge into the Linear Merge category:

On the other hand, Regular Merge (no fast Merge), Squash Merge, and Semi-Linear Merge (that is simply a combination of a (regular) Merge and a Rebase Merge). The Souce Control Tree is something like this: 

As we demoed like these:

Merge (no fast Merge)

Semi-Linear Merge:

 

Reference:


Similar Articles