Day 7: Git Advanced Concepts
Git Conflicts
When two developers work on the same repository and when developer1 created a file with some code which is in master branch. Now lets say developer 2 also created the same file and did he work in his file. Here both the developers are working on same file with difference in their code. Now when developer 1 tried to merge his file in master branch, git wont understand which code needs to be considered as both are having same file. Thus conflict arises.
Confused π€? Lets look into bash with example.
I have created a cherry.txt file in my master branch and added text called "Appl" into it and committed. I have another branch called newb. suppose lets say this branch is handling by another developer. This developer writes his own code called "Ball" from his side. Now this developer wants to merge his code into master. When he attempts merging conflict occurs π―
Because git wont understand which code to pick. So we need to resolve it.
To resolve the conflict, go to git status to see in which file the conflict occurs. In this case cherry.txt is having the conflict.
Open cherry.txt file you can see the conflict as below
Git wont understand which changes to be applied to this cherry.txt file. So we need to open the file and resolve the conflict. The code between <<<<<< HEAD is master branch code and >>>>>> is newb code. You can choose whatever code you want to keep in cherry.txt. and save.
Now you need to resolve this file by committing it.
Now our conflict is resolved.π
Git diff
Git diff shows the difference between changes in your working directory and staged area.
Ex: I added a file called c.txt. I staged it. I committed it. Now I want to modify c.txt. I made few modifications in c.txt. To know the difference in this file, prior to staging them, I wish to see that what I changed in my current working directory (that is the current working folder) compares with the staged changes.
πGit diff shows the difference between changes in your working directory and staged area --> means if you look at the below example, I staged c.txt(first time)
second time I modified the file but I didn't stage which means it is there in working directory. Now when I give git diff I can see the diff. If we didnt chnage anything in the working directory then it will show nothing. Beacuse there is nothing different while compared with the staged area. (See 2nd image)
Here a/c.txt is old file, b/c.txt is new file with modification
Here I moved c.txt to staging area by git add . so c.txt is not in working dir. So there is nothing to compare. Mkaing sense ? π€
Thats all about git diff π
Git restore, reset and revert
There are three commands with similar names git reset, git restore and git revert.
Useful when undoing bad commits while using Git.
git restore
When you want to unstage the file which is staged you can use restore.
Now lets say you committed d.txt, when you try to restore it , it wont be restored π because it already committed.
In this case you can use revert which is used to revert the commit π
Git revert
git revert 'specific commit id'
You can see that I actually gave git revert ce429fd which means d.txt is added is the commit. when i reverted , you can see there is no d.txt file because reverted commit was adding a file d.txt which is now not there. (Note:It wont actually delete the file but performs the commit.)
Now lets do 3 commits for d.txt and I want to revert the third commit.
I added 3 commits as below
You can see that latest commit is thrid commit for d.txt file. Now I don't want that commit and I want to undo it . I reverted using its commit id as below.
My third commit was I added 3rd line in d.txt file which is "Hey I am third file "
which is now not there π as I revert it.
reverted history can be seen using git log --oneline.
Note: Revert will also generates an hash/id βοΈ
Git Reset
So when reset will work? So far we have reverted to a specific commit which is having a issue or you want to revert. But In real scenario there will be continuous commits will be there with issues. So we cant revert each commit until you get your proper code file(with no issues) so in this case we use reset where we will reset set of commits.
Lets see in practical.
Here I need to reset the commits till 728db commit id. I performed soft reset.(This command git reset -soft is used to unstage the files which we have staged using the git add command.) Head will move to 728db commit id.
Here history of reset commits wont be displayed like it happened in revert. In revert whatever commits we have reverted that history will be known (look at fb07e35 commit) It is displayed as revert commit. But in reset that history wont be displayed.
That particular commit will be in modified state.
It means file will be having code with issue but it wont be in committed state. So you can modified the code and commit it.
Git Cherry-Pick π
Cherry-picking in git means choosing a commit from one branch and applying it to another branch.
I have 2 branches master and newb. I created a file in newb and committed it and I want to pick this commit and put into my master branch.
git cherry-pick commit id
Now cherry.txt is added into another branch which is picked from previous branch.
Cherry pick in same branch :
I have logs in my master branch where it shows commits. Now I want a specific commit to be picked and kept in first place as HEAD.
Example, I want 5b013a2 commit to be at first place. so I used git cherry-pick 5b013a2. But I got one conflict.
So the conflict here is git doesn't understand which one to select among the current head commit and chosen commit . So we need to resolve the conflict.
I will use git status to know which file is having conflict. When opened that file we can see git automatically added few lines.
Here hi bye is the commit of current HEAD. and hi is the commit of chosen commit.
you can edit as per your req. I will keep hi and save it.
I added to stage and committed with new message. when we view logs that commit will come under HEAD.
Git Merge and Rebase
We can integrate one branch with another branch using git merge and rebase.
Merge preserves the branch history whereas rebase doesnt.
Initially, in master branch, I have m1 commit. From master I created a another branch called feature and committed f1 feature. Now m1 and f1 will be there in feature branch. Now I will go to master branch and created another commit which is m2. and when I go to feature branch, m2 wont be available. So we merge master branchwith feature branch. m2 will be merged into feature branch which will be pointed as HEAD.
I have logs of master and branch1
I added a new commit called rainbow.txt in master. I will merge master into branch1.
only unadded commit will be merged into branch1.
rebase:
β
Moves entire feature branch to the tip of master branch.
Existing branches are not changed any way as in happened in merge.
Creates a new merge commit in feature branch. Rewrites the project history.
Git Squash
Squash generally means press or squeeze or combine. Now in git terminology, squashing is combining commits into one commit.
Let's say I have 3 commits under the feature branch. I can squash these 3 commits into one single commit.
Let's perform squashing now. I have a feature branch with file4,5,6 files and their commits. I want to squash these 3 commits into a single commit in master.
use
git merge --squash feature && git commit -m "msg"
you can see that feature branch commits were squashed into single commit with commit msg.
This is called squashing.
Git Clone / Fork / Pull / Push
git clone
means you are making a copy of the repository in your system.
git fork
means you are copying the repository to your Github account.
git pull
means you are fetching the last modified repository.
git push
means you are returning the repository after modifying it.
In layman's term:
git clone
is downloading and git pull
is refreshing.
--THANK YOU FOR YOUR TIME. HAPPY LEARNING--
--SUGGEST OR COMMENT IF YOU LIKE MY BLOGS π--
Subscribe to my newsletter
Read articles from Aasifa Shaik directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Aasifa Shaik
Aasifa Shaik
I am a DevSecOps Engineer at Renesas, where I specialize in integrating security practices within the DevOps pipeline. My work focuses on automating security, ensuring compliance, and securing applications throughout their lifecycle.