y the hash of your previous commit from here and paste in the command prompt. It will look like this.
Now we will run the following command.
git reset --hard "commit hash"
This forces our remote repository projects files to be the state they were in, when we made that particular commit, regardless of what we have now.
When we do so, we’ll receive the message that we are one commit behind. Meaning git counted this action as another commit and now you have some changes in your remote repository.
Let’s now fetch these changes without merging them into the directory and selectively doing the merge by ourselves. To do so, we’ll run the git fetch command as follows:
git fetch --all
This will fetch all the commits that we don’t currently have, but without merging them or affecting our workflow. So let’s actually add a few words in our text file, I’ll add the words ‘we made’ after the word ‘project’ on the third line.
I’ll then add and commit these changes. Now our local repo has a commit that our remote doesn’t have, and our remote has a commit that our local doesn’t have. What to do then?
Well, let’s try to use the
command and see what happens. We get the message that we have a “Conflict”, the automatic merge didn’t work and we need to fix these conflicts by ourselves.
On my VS code, I can clearly see these conflicts and the actions I can take to resolve them. If you’re not using VS code, do not worry, most editors support conflict management.
I have 4 options, ‘Accept Current Change’, ‘Accept Incoming Changes’, ‘Accept Both Changes’ and ‘Compare Changes’.
I will choose to accept both changes to showcase the different options, but of course, in this situation, you should choose the most appropriate. Now, this is how the text file looks like:
At this stage, what you ideally do is click on either “Accept Current Change” or “Accept Incoming Change”, depending on what changes you want to keep and what you want to discard.
Once done, we’ll finalize the merge by committing our changes.
We’ve mentioned branches a lot so far, and it’s about time we explain what branches are. Branches are one of the most powerful features in Git.
There are many use cases for branches, for example, if you’re working on a software with different releases, development of the different versions shouldn’t be going on the same pipeline. Branching is basically diverging the flow of changes in a certain direction.
Another more general example is a production, testing, and development branches, production would only contain stable releases, certain development commits would have to diverge to testing before they’re merged with production and so forth. It’s a much-needed practice in the software world.
The reason why Git is so good at branching is that it’s using snapshots and calculating differences, the process of creating a branch then becomes much simpler and faster than it is in other systems like SVN where such operation is a headache.
So let’s start a new branch on our project, we can simply do so by using the git branch <branch name> command which will go ahead and create a new branch with the name we choose.
We can then enter that branch by using the following command:
git checkout "branch name"
I’ll go ahead and edit branch ‘testing’ with a change in the text file as follows, and I’ll commit this change. You can run
to commit all the unstaged files and commit them with the same command.
Here you can find some best practices for branching: Git Branching Model
Pull requests are used to discuss some piece of code with the other collaborators before finally merging the code. They can be useful if you are contributing to an open source project or have some people working remotely. You can specify which branch you’d like to merge your changes into when you create your pull request.
To create a pull request, first, you need to create a new branch from the branch you wish to merge into. Next, you need to commit some changes and push this branch to Github.
You will find the “New pull request” button on the repository page. On clicking it, Github will show you t