Error in commit ... How to fix it? Confusion in the history of commits ... How to bring everything into a decent look? The author of the article, the translation of which we publish today, says that it was written specifically for those who asked such questions. According to him, after studying the techniques of working with Git, presented here, you can significantly advance the path of mastering Git.
It is assumed that the reader of this article is already familiar with the basics of Git. If this is not the case, it is first recommended to master the base, for example, using
this material.
Correction of errors in commits
Here we consider several scenarios for the appearance of errors in commits and their correction.
â–ŤScenario number 1
Suppose you commit a lot of files and understand that the commit message was not particularly clear. After that you decided to change this message. To do this, use the
git commit --amend
. Here is an example of its use:
')
git commit
â–ŤScenario number 2
Suppose you wanted to commit six files, but, by mistake, commit only five. It seems that you can correct this error simply by creating a new commit and adding the missing sixth file there.
Such an approach is completely entitled to life. But in order to keep the history of commits in good condition, it would probably be much better to be able to add a randomly missed file to the same commit. This can be done, again, with the
git commit --amend
. Its use looks like this:
git add file6 git commit
The flag
--no-edit
means that the commit message does not change.
â–ŤScenario number 3
To the commits that make in Git, the name of the author and his email address are attached. Usually this data is indicated by performing the initial Git setup. As a result, the one who uses Git may, by performing each commit, not worry about the details of its author.
In this case, it is quite possible that, when working with some projects, you will need to use information about the author, for example, an email address that is different from the main ones. For such a project, you must specify the email address using the following command:
git config user.email "your email id"
Suppose you forgot to perform this setup and have already made the first commit. The
amend
command already familiar to us can
amend
. With its help you can change the information about the author of the previous commit:
git commit
â–ŤNote
Use the
amend
command only in your local repository. Using it in remote repositories can be a huge mess.
Bringing order to commit history
Suppose you are working on a piece of code from a project. You know that it will take about ten days. During these ten days, other developers commit to the source repository.
It is recommended to maintain synchronization between the local and remote repositories. This avoids many of the merge conflicts that occur when synchronization of repositories is too rare. Following this practice, you decide to download changes from a remote repository every two days.
Each time you download code from a remote to a local repository, a new merge commit is created in the local repository. This means that in your local commit history there will be many such commits that can confuse the person who will view your code.
The history of commits in the local repositoryHow to put a commit history in order? To solve this problem, you can use the
git rebase
.
â–Ť git rebase command
Consider the
git rebase
with an example.
Commits in the release branch and in the feature branchIn the
Release
branch there are three commits:
Rcommit1
,
Rcommit2
, and
Rcommit3
. You created your
Feature
branch from the
Release
branch when there was only one commit in it -
Rcommit1
. After that you added two commits to the
Feature
branch. These are
Fcommit1
and
Fcommit2
. Your goal is to download commits from the
Release
branch to your
Feature
branch. In order to do this, you are going to use the
rebase
command.
We will use the names
release
and
feature
for the two branches in question.
As a result, using the
rebase
will look like this:
git checkout feature git rebase release
â–ŤRebase command features
The
rebase
command
rebase
used to ensure that the
Feature
branch
Feature
fresh code from the
Release
branch.
When using this command, the system tries to add each commit to the
Feature
branch, one at a time, and check for conflicts. If it sounds difficult - let's consider the following figure. This shows the internal mechanisms for the
rebase
.
Feature branch and three steps of the rebase commandStep 1
At the moment of calling the command, the
Feature
branch points to the head of the
Release
branch. After that, there are three commits in the
Feature
branch:
Rcommit1
,
Rcommit2
, and
Rcommit3
. Perhaps, here you will have a question about what happened to the commits
Fcommit1
and
Fcommit2
. These commits have not gone away; they will be used in the next steps.
Step 2
Now Git is trying to add the
Fcommit1
commit to the
Feature
branch. If there is no conflict,
Fcommit1
added after
Rcommit3
. If a conflict is detected, Git will report this and you will have to resolve this conflict manually.
Step 3
After the commit
Fcommit1
added to the
Feature
branch, Git tries to add
Fcommit2
to the same
Fcommit2
. Here, again, if there are no conflicts, then
Fcommit2
added after
Fcommit1
and the operation is successfully completed. If a conflict is detected, then Git, as before, will report this and offer to deal with it.
After the completion of the
rebase
command
rebase
you will see that there are commits
Rcommit1
,
Rcommit2
,
Rcommit3
,
Fcommit1
, and
Fcommit2
in the
Feature
branch.
â–ŤNote
When working with Git, both the
merge
command and the
rebase
command are
rebase
. It cannot be said that one of them is preferable to the other.
If you use the
merge
command, you will get a commit-merge. If you use
rebase
, you will not have any additional
rebase
.
It is recommended to use these commands in various situations. So,
rebase
is suitable for updating the local repository code based on fresh code from a remote repository. Use the
merge
command when executing pool queries to merge the
Feature
branch with the
Release
or
Master
branch.
Results
After examining the concepts presented in this material, you have improved your Git skills and come closer to the level of a Git expert. We hope that what you have learned here will be useful to you. But the world of Git is huge, therefore, having mastered something new, do not stop there and move on.
Dear readers! Did you encounter confusion in git commits?
