remote: A <- B <- C <- D 

local: A <- B* 

(*indicates that you have several files which have been modified but not committed.)

Two methods are used to deal with this scenario. Discarding the changes in files or retaining them are them.

Method one: Throw away the changes

This approach allows you to selectively discard changes in specific files. You can use git checkout followed by the file name to restore the file to its state in the last committed (HEAD) version. This method resets all the files in your working directory to the state of the last commit (HEAD), effectively discarding all changes you made locally.

remote: A <- B <- C <- D 

local: A <- B

Hence, when you pull. We can also fast-forward the branch while considering the changes from the master. Thus, after pulling, the branch will look similar to a master:

local: A <- B <- C <- D

Method two: Retain the changes

We know that if you need to keep those changes. The initial step is to resolve those merge conflicts in each of those files. Thus, we can open each file in your IDE and check for the following symbols:

<<<<<<< HEAD 

// your version of the code 

======= 

// the remote's version of the code 

>>>>>>>

Git presents you with two versions of the code: the one from your current local branch (between <<<<<<< HEAD and =======) and the one from the remote repository (between ======= and >>>>>>>). You manually choose which changes to keep and which to discard by editing the conflicted file. After resolving the conflicts, you remove the conflict markers and save the file. You used git add to stage the resolved file. Finally, you commit your result with an appropriate commit message. The diagram will look like the following:

remote: A <- B <- C <- D 

local: A <- B <- C'

Here, we can provide labeling to commit as C since it is very different from the commit C. Whereas if you want to pull, you can get a non-fast-forward error. Git won’t play the changes in remote on the branch. Since, both that branch and remote will be separated from the common ancestor commit B. We can conclude that if you want to either do another git merge or git rebase your branch on the remote.

Hridhya Manoj

Hello, I’m Hridhya Manoj. I’m passionate about technology and its ever-evolving landscape. With a deep love for writing and a curious mind, I enjoy translating complex concepts into understandable, engaging content. Let’s explore the world of tech together