Since my introduction to the git workflow. I have resolved my own fair share of conflicts. Admittedly when I started using git, conflicts were frustrating and upsetting occurrence mainly because I didn't understand why and how they occurred.
Unwittingly I actually thought they were something I could avoid, I thought there was a way I could outsmart git, hahaha! The word conflict has a negative connotation to it so don't blame my newbie response.
I remember during my BootCamp at Andela, we worked in such a way that you could only merge your pull request to the main develop branch if it had been reviewed and then approved.
So my genius way of ensuring I totally avoided conflicts, was to wait and have my PRs approved and consequently merged to the develop branch one at a time and that impacted negatively on my overall output.
The reason I feared conflicts was the first time I was ever brave enough to queue up my PRs I made a giant mess trying to resolve the conflicts and lost all my work.
Anyways all the previous tutorials I had followed up to that point had only covered git clone, pull and push, I honestly didn't know we made war in git!
In this series, I document my steps in re-creating and hopefully resolving my favorite conflicts.
Keywords
- HEAD: normally the HEAD pointer, points to the latest commit on a branch you have currently checked out.
- History: Git works by compiling information about details of commits of individual branches if you run the command
git logyou get the history of a branch you have currently checked out. Then git log --oneline prints each commit on a single line, which is useful if you’re looking at a lot of commits.
Creating the conflict
To get started I created a repo on github initialized it with a README.md and cloned it on my machine.
Then on VS code, I opened
Using the command,
git checkout -b create-bio
I branched off master and created a branch called create-bio and then checked out create-bio.
create-bio is normally referred to as a feature branch. Its good practice to open a branch for every feature than work on your master. This ensures you only merge to master the code that works and your work is clean.
After that I then created a file called bio.txt and added a simple unimaginative line of code to it:
A git environment can be broken down into two distinct parts. The remote repository is where you push the code you want to share with others which in my case is hosted by Github and your development environment. The development environment consists of the working directory, staging area, and local repository. So basically when using git workflow, when you clone your repo from the remote it comes with a .git folder. That folder is basically the local repository.
In essence, Git is a clever piece of software that not only ensures that you can track your files it also allows you to share them as well. Under the hood, git works by persisting branches and commits.
The working directory is just that, the stuff you work on. So as you work you have to naturally keep track of the files you are working on and to do that you add them to the staging area.
So to track bio.txt. I add it to the staging area by running the command,
git add .
Using the command,
git commit -m "Adds bio.txt"
I add bio.txt to my local repository it's official, the changes I was tracking have been committed to my local repo.
Remember when I started off I cloned my remote repository and it only had the master branch now that I've created a new branch in my local. The local and the remote are out of sync so using the command,
git push --set-upstream origin create-bio
I create the branch create-bio in the origin/remote and simultaneously push the changes in that branch to the remote repo.
So far all things are fine and dandy, to introduce some chaos I then edit the file bio.txt ever so slightly,
If u run the command,
git status
You will see that the bio.txt has been modified. So to add the changes I made to bio.txt to the staging area I run the command
git add .
This time to add my staged changes to my local I use the command,
git commit --amend --no-edit
The command above allows me to combine staged changes with the previous commit instead of creating an entirely new commit. This git views as an entirely new commit, history has been re-written.
To verify that history has been altered, if I log my git history on the terminal, although the commit message is the same for the tip of the branch before and after running the command git commit --amend --no-edit the commit hashes (i.e. the string that precedes the commit message) are different as shown below:
f780b5d (HEAD -> create-bio, origin/create-bio) Adds bio.txt
7619836 (origin/master, origin/HEAD, master) Initial commit
PS C:\Users\\Desktop\git-tut-1> git commit --amend --no-edit
[create-bio 1b61b25] Adds bio.txt
Date: Thu Oct 10 03:30:45 2019 +0200
1 file changed, 3 insertions(+)
create mode 100644 bio.txt
PS C:\Users\\Desktop\git-tut-1> git log --oneline
1b61b25 (HEAD -> create-bio) Adds bio.txt
7619836 (origin/master, origin/HEAD, master) Initial commit
If you run the command,
git status
The message you get on the terminal is:
On branch create-bio
Your branch and 'origin/create-bio' have diverged,
and have 1 and 1 different commits each, respectively.
(use "git pull" to merge the remote branch into yours)
I then attempt to sync my remote to my local, by running the command,
git push
On the terminal I get the error:
As advised in the error message, I then run the command,
git pull
And voila the message on the terminal reads:
CONFLICT (add/add): Merge conflict in bio.txt
Auto-merging bio.txt
Automatic merge failed; fix conflicts and then commit the result.
The conflict on VS Code:
Resolving the Conflict
Using VS Code editor it's very easy to resolve the conflict I simply choose to Accept Current Change, this option allows me to keep the changes in the HEAD.
You can then play around with the other options to explore how they work. Just ensure when you are done resolving the conflict your code looks normal as in you have gotten rid of the arrows, commit hash, and equal signs.
I then run the command,
git add .
To add changes to the staging area, then proceed to commit them by running the command
git commit -m "Resolved"
After which I run the command:
git push
So my local and remote are in sync.
Top comments (1)
Great post! Thanks for sharing :)