With the rise of DevOps technologies, it has become unavoidable for any IT professional to work on many data sets at the same time, and the data is always changing. It’s also crucial to keep track of every update to the data and be ready to undo or reverse any unwanted changes if necessary.
Using Git to version data allows being more adventurous in the creation of projects. If a mistake is made, it is known that git will always allow undoing and/or revert that version of the project to the state it was in before the mistake was made. Before forwarding the data to the next level, each Git process layer is designed to allow the data changes to be reviewed, changed, and/or rectified. As a result, the following are the blunders that occur and are addressed in this article:
1. Remove files and folders from the Index: The default functionality of the ‘git add’ command is used to add all files and directories to the Index when adding and/or changing files. There may be a requirement to un-stage or change specific files one final time before committing them.
Errors Caused due to removal of files and folders
Syntax-
git reset <filename/dirname>
2. Forgot some changes in the last commit: If the user forgot to make some changes and previously committed the snapshot and the user doesn’t want to commit again to point out the error.
Syntax-
git commit –amend
Output 2. Output from amend command.
3. Edit the most recent message that was committed: It is possible to make changes to the most recent committed message without having to create a new one. Below is the sample command where an alias ‘hist’ is created to list the committed logs.
Syntax-
git config –global alias.hist ‘log –pretty=format:”%C(yellow)%h%Geeks%ad | %C(green)%s%Geeks%C(blue)%d%for Geeks %C(red)[%an]” –graph –decorate –date=short’x
Fixing the most recent message
Output 3. Output from config command.
4. Personal data has been committed to a local repository: Sometimes it may happen that the photo saved from the phone’s camera goes to the commit folder and gets pushed. Now it is required to delete certain files from the working directory but keep others in the local repository.
Syntax-
git reset –mixed HEAD~
git reset –mixed <commit-id>
Output 4. Output from local command.
5. Changes made locally should be ignored: Let’s take an example of an updated and staged ‘README’ file. Then a second edit is done to the same file. But it was not a required change.
Syntax-
git checkout — <filename> –local changes in a file
git checkout — <dirname> –local changes in all the files in the directory
Output 5. Output from checkout command.
6. Replace the previous commit with a new one: The ‘–soft’ option just removes committed files from the local repository while they remain staged in the Index, allowing one to re-commit them after a review. Let’s say there is a need to delete the SHA-1 of the snapshot from the local repo is commit-id. <Head -n> where n is the number of commits before the HEAD commit.
Syntax-
git reset –soft HEAD~1
Output 6. Output from reset soft head command.
7. Committed the wrong data: Sometimes it happens that the user commits the wrong data to the repository. Let’s see how to reset the project to the state before committing the wrong data.
Syntax-
git reset –hard HEAD~n –reset the project to ‘n’ commits before the latest committed snapshot
git reset –hard <commit-id> –reset the project to given commit id snapshot
Output 7. Output from reset hard command.
8. Getting back to the old project state: The fastest and the cleanest way to go back to the old project state is using the reset command in git along with the –hard flag so that everything comes back to its previous state.
Syntax-
git reset –hard <branch-number-here>
Output 8. Output from hard command.
9. Recovering a Deleted Local Branch: Sometimes, by the virtue of a small mistake, some important local branch might get deleted before it was pushed. In that case, the below command (checking out) will certainly help to recover that lost file.
Syntax-
git checkout -b <branch> <sha-keypair>
Output 9. Output from SHA command.
10. Fixing the wrong name given to a branch: Sometimes the branch that was just renamed had some typo like Geeks for Geeks became forGeeks, or maybe the user does not like the branch name enough and wants to rename it using a command line. The below command can be used to achieve the same:
Syntax- Targeting Old Name
git checkout <old_branch_name>
Syntax- Fixing and renaming now
git branch -m <new__branch_name>
Output 10. Output from branch command.
11. Re-arranging the history log: It might be really great if some commits are pooled together and then concatenate the commits into one big commit and rearrange them further. To achieve that, git provides an easy way out.
Syntax-
git rebase –interactive <some_random_autogen_id> <your_order_here>
Output 11. Output from interactive command.
And that’s it, just keep placing the commit order in the place and the commits will keep arranging.
Note: The above method works on local commits, not the one which is pushed.
12. Mistakes with GitHooks: Git hooks are a fantastic method to check the code when the changes are committed. They are simple scripts that live in the.git/hooks directory of the local repository. Depending on the name of the hook, these scripts are done at certain moments during the local process. While working on a big collaborative project, sometimes one may encounter some errors. Let’s see how to avoid that. One could simply just redirect the output to stderr, which will alert and notify the user on the email as well as the desktop if some error creeps in, even better if the commit you are about to push could cause some error, it will alert you for that as-well.
Including this in your project is quite simple, just do:
# Performing some random task here
perform 1>&2
# Redirecting the output to stderr.
FORBIDDEN=’todo: fix this’
# A simple method to return what you need to do if you encounter this.
git diff –cached –name-only | \
xargs grep –with-filename -i -n “$FORBIDDEN” && echo “COMMIT REJECTED
Found ‘$FORBIDDEN’ references. Kindly alter the changes or remove them
before committing ” && exit 1
exit
# The program quits
No output as the githook executed successfully.
And just like that you took care of that possible githook mistake, and can continue on your project as earlier! All these were the most frequent errors which you can expect to happen in a day-to-day Git Experience Scenario. Handling them gets a breeze when you know the perfect syntax for it!
Share your thoughts in the comments
Please Login to comment...