Git happens! 6 typical git errors and how to fix them

Note trans. : The other day in the blog for engineers of our beloved GitLab project, a small but very useful note appeared with instructions that help save time and nerves in case of various problems that occur as you work with Git. It is unlikely that they will be new for advanced users, but there are also those who will find them useful. And at the end of this material we added a small bonus from ourselves. Good Friday everyone!

We all make mistakes, especially when dealing with such complex systems as Git. But remember: Git happens!
')
If you're just starting out with Git, learn the basics of working with it on the command line. And here I’ll tell you how to fix the six most common errors in Git.

1. Oops ... I made a mistake in the message to the last commit

After several hours of coding, it is easy to make a mistake in the commit message. Fortunately, this is easy to fix:

git commit --amend

A text editor will open with this command and allow you to make changes to the message for the last commit. And no one will know that you wrote "addded" with three "d".

2. Oops ... I forgot to add the file to the last commit.

Another popular bug in Git is a too hasty commit. Did you forget to add the file, forgot to save it, or should you make a small change for the commit to become meaningful? Your friend will again be --amend .

Add the missing file and execute this valid command:

 git add missed-file.txt git commit --amend

Now you can either correct the message, or simply keep it in its previous form (with the file added).

3. Oops ... I added a file that should not be in this repository.

But what if you have the opposite situation? What if you added a file that you don’t want to commit? Deceptive ENV-file, assembly directory or photo with a cat that was accidentally stored in the wrong directory ... Everything is solved.

If you have only made a stage for a file and have not committed it yet, everything is done through a simple reset of the desired file (located on the stage):

 git reset /assets/img/misty-and-pepper.jpg

If you did commit the change, you will need an additional preliminary step:

 git reset --soft HEAD~1 git reset /assets/img/misty-and-pepper.jpg rm /assets/img/misty-and-pepper.jpg git commit

The commit will be rolled back, the picture will be deleted, and then a new commit will be made.

Note trans. : As noted in the comments to the original article, this problem can also be solved with the help of the already mentioned --amend . Apparently, the author wanted to show with this item what other ways to change the commit history to correct the error.

4. Oops ... I commit changes to the master.

So, you are working on a new feature and hurried, forgetting to create a new branch for it. You have already committed a bunch of files and all these commits are in the master. Fortunately, GitLab can prevent push'y directly into the master. Therefore, we can roll back all the necessary changes to the new branch with the following three commands:

Note : Be sure to commit or stash 'zeros of your changes first - otherwise they will all be lost!

 git branch future-brunch git reset HEAD~ --hard git checkout future-brunch

A new branch will be created, in the master, a rollback to the state in which it was before your changes is made, and then a checkout of the new branch with all your changes is made.

5. Oops ... I made a mistake in the name of the branch.

The most attentive could notice in the previous example an error in the name of the branch. It is almost 15:00, and I still have not had dinner, so my hunger called the new branch ( br a nch ) as future-br u nch . Yummy!

Rename this branch in the same way, which is used when renaming a file using the mv command, that is, placing it in a new location with the correct name:

 git branch -m future-brunch feature-branch

If you have already pushed this thread, you will need a couple of extra steps. We will remove the old branch from the remote and push the new one:

 git push origin --delete future-brunch git push origin feature-branch

Note trans. : You can also delete a branch from a remote using:

 git push origin :future-brunch

6. Oops ... I did it again!

The last command in the case when everything went wrong. When you copied and installed a bunch of solutions with Stack Overflow, after which everything in the repository became even worse than it was at the beginning. We all once came across a similar ...

git reflog shows a list of all the operations you have performed. It then allows you to use Git’s magical time-travel capabilities, i.e. back to any moment from the past. I should note that this is your last hope - you should not resort to it in simple cases. So, to get the list, run:

 git reflog

Every step we take is under the watchful eye of Git. Running the command on the project above issued the following:

 3ff8691 (HEAD -> feature-branch) HEAD@{0}: Branch: renamed refs/heads/future-brunch to refs/heads/feature-branch 3ff8691 (HEAD -> feature-branch) HEAD@{2}: checkout: moving from master to future-brunch 2b7e508 (master) HEAD@{3}: reset: moving to HEAD~ 3ff8691 (HEAD -> feature-branch) HEAD@{4}: commit: Adds the client logo 2b7e508 (master) HEAD@{5}: reset: moving to HEAD~1 37a632d HEAD@{6}: commit: Adds the client logo to the project 2b7e508 (master) HEAD@{7}: reset: moving to HEAD 2b7e508 (master) HEAD@{8}: commit (amend): Added contributing info to the site dfa27a2 HEAD@{9}: reset: moving to HEAD dfa27a2 HEAD@{10}: commit (amend): Added contributing info to the site 700d0b5 HEAD@{11}: commit: Addded contributing info to the site efba795 HEAD@{12}: commit (initial): Initial commit

Pay attention to the leftmost column - this is the index. If you want to return to any point in the history, execute the following command, replacing {index} with the corresponding value (for example, dfa27a2 ):

 git reset HEAD@{index}

So, now you have six ways to get out of the most frequent Gitfalls (pun: pitfall means “trap, error” - approx. Transl. ) .

Translator Bonus

First, a valuable remark to everything written above (except for paragraph 5). It should be borne in mind that these actions change the commit history, so they should be carried out only if the changes were not sent to the remote (push). Otherwise, the old bad commit will already be on the remote branch and you will have to either perform git pull (which will make a merge , and then trying to “clean up” the story will lead to worse consequences), or git push --force , which is fraught with data loss when working with a branch of several people ...

Now - small useful additions from our experience:

If you (accidentally or not) have changed a branch and you need to return to the previous one, the fastest way is to use git checkout - .
If you accidentally added a file to a commit that should not be added there, but have not yet made a commit, use git reset HEAD path/to/file . A similar situation is described in paragraph 3, but in reality it is wider, since refers to any unnecessary changes in the commit (not just the case of an extra file).
A good practice not to commit too much is to use the -p option when adding a file to a commit ( git add -p ). This allows you to review each change that will go to the commit. But it is worth remembering that it does not add untracked files to the commit — they need to be added without this parameter.
A number of good recommendations (including more complex ones) can be found in the 2014 article " Git Tutorial: 10 Common Git Problems ." In particular, note the use of git revert and git rebase -i .