Git Merge, Squash, Rebase, or Pull — What To Choose?

A step-by-step comparison for resolving Git conflicts

Photo by Paul Steuber on Unsplash

A Git repository is a version control system that tracks file changes. With a large number of software developers working off different branches, merging everyone’s work and resolving conflicts becomes an ongoing challenge.

In a previous article, Git references, commits, and branches are described. Assisted by a handful of Git commands, we have demonstrated how to recover from a merge mess.

In this article, we are going to use examples to show how to avoid a merge mess using the choices of merge, squash, rebase, and pull.

The Conflict Case

We have created a repository with conflicts, which can be cloned by the following command:

$ git clone https://github.com/JenniferFuBook/git-merge-conflicts.git

There are two branches, main and feature, in the repository.

As we specified in the previous article, git log —-graph draws a text-based graphical representation of the commit history on the left-hand side of the output. Each * represents a commit, and the incoming lines under * represent the parent commits. Multiple incoming lines indicate a merge, while outgoing lines mark a common ancestor.

The --all option lists the history of all branches.

After feature branched off main, they both modified file.txt (line 14 and line 8). When feature syncs with main, it gets two changes:

• newFile.txt that main creates (line 2): There is no conflict.
• file.txt that main changes (line 8): There is a conflict.