Github Tutorial 2: Committing specific files, Rollbacks, Merge Conflicts.
In the previous tutorial, we focused on understanding the basic fundamentals of Git. Git checkout, pull, commit, push. You can take a look here: https://www.dhirubhai.net/posts/yash-shirodkar-a0886a159_git-tutorial-activity-6892589740986892288-_iCp
In this tutorial we will focus on:
Committing specific files only
You and your colleague might be working in the same branch, and you would want to commit your changes. As you can see below there are two files with changes and you want to commit SVR.R only:
You simply use git add filename to add a specific file to the staging area. This only adds a specific file to the staging area.
After pushing the code you can see below that only SVR.R has committed changes:
Git Rollbacks: Reset vs Revert
If a commit has been made somewhere in the project’s history, and you later decide that the commit is wrong and should not have been done, then?git revert?is the tool for the job. It will undo the changes introduced by the bad commit, recording the “undo” in the history.
If you have made a commit but haven’t shared it with anyone else and you decide you don’t want it, then you can use?git reset?to rewrite the history so that it looks as though you never made that commit. If you wish to undo all local changes simply use
git reset --hard
A great visualization can be seen here-
领英推荐
Merge Conflicts
Merge conflicts occur when two developers are trying to change the same line of code at the same time on the same or different branch.
In the above example, I have created two feature branches: feature1 and feature2 and will try to make some changes to Polynomial_Regression.R at the same time. When you try to merge, something like this happens-
Git is unable to figure out which line of code is the right one.
If you open the file in a text editor– in my case: Polynomial_Regression.R you will see something like this:
Think of these new lines as “conflict dividers”.
The?=======?line is the “center” of the conflict. All the content between the center and the?<<<<<<< HEAD?line is content that already existed before we tried to merge ‘feature1’. Alternatively, all content between the center and?>>>>>>> feature1?is content that is present in feature1.
Solving a merge conflict:
If your code is thousands of lines big, scrolling up and down to see where the conflict occurred can be tedious. The simplest way to find it using ‘git diff’ on the terminal -
The easiest way to resolve merge conflict is to edit the file in an editor. I removed the unnecessary texts. Once done, simply do a git commit and a git push. Voilà! You are set.
If you open the file, you will see only the changes you wanted: