To begin with, git is a tool, and it is essential for every developer working with a team. Being good at it feels really awesome and can get your work done easily when working with a team on the same project.

In this guide, we will work on git and how we can recover lost files in git manually and using 

. We will demo using examples to get your hands on.

 is essential in this guide, you should also be able to know the basics

: A commit is a snapshot of your repository at a specific point in time. Each commit has a unique hash identifier.

: This command allows you to apply the changes introduced by existing commits from another branch into your current branch.

 This command is used to switch branches or restore working tree files. It can be used to recover files from a previous commit.

: Reflog is a mechanism in Git that records updates to the tips of branches and other references. It allows you to view the history of all actions performed in your repository, even those not reachable by branches. This can be particularly useful for recovering lost commits, which come in handy at a later stage in this article.

The output will look something like this below.

 means "where HEAD used to be one move ago".

You can have it followed by the number (optional) to give you how many you want it to show in the front and tail, 

: Provides detailed information about each entry.

: Adjusts the reflog entries to reflect changes such as rewritten commits.

: Limits the number of entries displayed.

And there are many more options to tailor the output to your needs. You can learn more about it here.

 will return the last two entries in the Git reflog. Each entry in the reflog represents a change or update to the tip of branches or other references. By specifying 

, you're limiting the output to just the two most recent changes.

Here's an example of what the output might look like:

 or description of the action (update: subscribe and update: footer).

The Danger Zone: Accidentally deleting a file.

 and navigate into it using the commands 

. Initialize a Git repository in this directory with the command 

. Add content to these files; for example, in 

, you could start with `# Project Name` and in `CONTRIBUTING.md`, begin with `# Contributing Guidelines`.

Moving forward, let’s add the files to the staging area and commit them. Use the commands 

. As stated earlier, we might work with a team and would want to contribute. Therefore, we need to create a branch where we can make our contributions. 

You can do this by running the following command from the main branch (it might be different on your end - my branch is named ‘trunk’): 

. This command creates a new branch name contribution (if we don’t already have one) and switches to it.

let's make some changes to the changes to the files, you can edit any of the files. You can run this command to add some text to the contributing file. 

echo 'this is my first message' >> CONTRIBUTING.md

 or you can edit it manually, whichever way you like. When you check the 

 (`git status`) you will see that you've modified the file. You can then a

Now let's delete it. We assume that we may delete the branch accidentally by the command 

 but first checkout to your main branch - in my case 

And if you check the branch, you will notice that you only have one branch, the 

Your hard work of contributing has gone that way? you've completely deleted your branch. If you check the history, you won't find it. How can we recover it? Well, we have 2 ways we can do it.

 the last 3 history commits we made. Run the following command 

You can see our history and our changes. We see our last commit - 

. With that, we can rebuild the whole repo just from this little, tiny sha.

When you run the above command, you can see it is right here with us. This means that even if we deleted a branch, it doesn't mean we deleted what we've changed. Our files are on the computer. And so, we can retrieve it from git.

To check the tree info, you can run the following command:

git cat-file -p 50e8badf9e1cbb8ddad75e5bd095d5a5c34fc0af

then if we then `cat-file` it with the following command,

git cat-file -p 8e835656024de97bbf7cfe5cfe858dad9d810a7d

 we can see what we wrote/updated earlier.

: You can cat it out into a different file and save it there. that's it. You can do the same with files that you created differently and cat it out the changes.

You're now getting a promotion. Let's keep going.

That seems hard to go by. Well, we have a quicker and easier way to do it. This might be your first time hearing it, if not, well let's get along, it is by using the 

' earlier and how to get it, right? 1e3b6f3. And if I would need these changes to my 

 branch I would just merge it using the same sha by running:

Look at that, we have our changes we made on contributing branches to our trunk branch. We could just bring it in. This is super easy, yeah? We didn't have to do the magical-hacker thing we did earlier right? Yaayyy!!


: Your commit ‘sha’ is a key piece of information.

, this doesn't end here, we may have some problems with merge - If histories have diverged far enough, this could cause some problems as you wouldn't just be merging the one commit, but all the commits in between 

 Given one or more existing commits, apply the change each one introduces, recording a new commit for each. This requires your working tree to be clean (no modifications from the HEAD commit).

You can learn a bit from it by running the 

Cherry pick allows you to take just one or more commits, specifically. Maybe at any time you just have that change and don't want to merge it, you can cherry pick it in. It works with remotes - as long as you're up to date with it and you can cherry pick it in if you need to.

Well, the ball this time is on you, if you did not merge the above changes, you can cherry pick it by running the following command. git cherry-pick: 

. And that's it, you will merge right in. Fantastic.

Recovering accidentally deleted files in Git can be straightforward if you know the right commands. By utilizing git reflog and git cherry-pick, you can easily restore lost files and continue your work seamlessly. Practice these methods to become proficient in handling such situations.

Develop your programming skills with tutorials in our blog. We cover a wide range of programming languages and technologies. Whether you are a beginner or an experienced developer, you will find something useful here.

Develop your programming skills with tutorials in our blog.

Tutorials

Mastering Manual File Recovery: A Guide to Cherry-Picking Deleted Files

Being able to effectively navigate and alter your project's history using Git can be invaluable. This capability not only helps in correcting mistakes but also in understanding the evolution of your project. This tutorial will guide you through the use of 

, two powerful commands that allow you to manage your project's timeline safely and effectively. Understanding the implications of these operations is crucial to avoid disrupting your workflow and maintaining the integrity of your codebase.

 command is primarily used to switch between different branches or to restore working tree files. It's a way to navigate through the snapshots of your project that have been captured in commits.

 to view the commit history and find the commit hash you're interested in.

Tips on navigating through the commit log:

 to see a visual representation of your project's branches.

Detached HEAD occurs when you check out a commit, branch, or tag that is not the tip of a branch. Here’s how it happens:

When you check out a specific commit that is not associated with a branch label, Git will warn you that you're in a 'detached HEAD' state.

To handle and exit detached HEAD state safely:

If you want to keep the changes you made in the detached HEAD state, start a new branch with 

If you want to return to the previous state, simply check out the branch you were on before, e.g., 


When you encounter a detached HEAD state in Git, it's essential to adhere to certain guidelines:

Recognize that a detached HEAD state is typically utilized for tasks such as inspecting older commits, reviewing historical states, or conducting specific tests or experiments. It's not intended for creating new commits directly.

Be cautious not to make new commits while in a detached HEAD state. These commits won't be associated with any branch, rendering them potentially unreachable and subject to eventual removal by Git's garbage collection mechanism.

To prevent the loss of changes, it's imperative to either create a new branch or handle the modifications appropriately before exiting the detached HEAD state. This ensures that your work remains accessible and integrated into the project's history.

Resetting Your Branch to an Earlier Commit

 alters the current HEAD and, potentially, the index (staging area) and the working directory depending on the specified options.

: Moves HEAD to the specified commit but leaves the staging area and working directory unchanged.

 (default): Resets the index but not the working directory.

: Resets both the index and working directory. All changes to tracked files in the working directory since the specified commit are discarded.

After resetting, you may need to push to a remote repository:

 to ensure you do not overwrite others' work.

Always communicate with your team when force-pushing, as it can affect shared branches.

Potential disruption for other collaborators.

You check out to a previous commit to test a new feature without affecting the main branch.

If the experiment fails, you can reset to align back with the main branch.

Workflow for complex project history manipulations

 to strip back unwanted commits before merging into main.

Navigating and Modifying Project History

Git offers a powerful feature known as "stashing" that allows developers to temporarily save changes without committing them. This tutorial will guide you through the essentials of using git stash, managing multiple stashes, and applying stashed changes back to your working directory.

 is particularly useful when you need to switch contexts quickly—say, from working on a new feature to fixing a critical bug—but you're not ready to commit the changes in your current branch. Here's how you can stash your changes:

To stash your changes, use the following command in your terminal:

This command temporarily stores all modified tracked files and stages changes, and then reverts them from your working directory. If you have any untracked or ignored files that you want to stash, you can use:

For better manageability, you can name your stash for future reference:

This is particularly useful when working with multiple stashes.

You might often find yourself juggling multiple tasks in the same repository. Git allows you to create and manage multiple stashes.

To see a list of all your stashed changes, use:

This will display a list of stashes, each identified by a stash index, starting from 

 command multiple times to create more stashes. Each new stash is placed on top of the stack.

To see the contents of a specific stash without applying it, you can use:

If you want to delete a specific stash, you can do so with:

3. Applying Stashed Changes Back to Your Working Directory

Once you're ready to continue working on your stashed changes, you can apply them back to your working directory.

To apply the most recent stash and keep it in the stash list, use:

If you want to apply the most recent stash and remove it from the list, use:

This command applies the stash and then removes it from the stack if there are no conflicts.

When applying a stash, you may encounter conflicts. Git will notify you of these conflicts, and you must resolve them manually. After resolving conflicts, you can continue your work and commit the changes as usual.

There may be instances where the changes in your current branch have diverged significantly from the changes saved in a stash, leading to potential conflicts when trying to reapply the stash. One effective solution is to create a new branch directly from the stash:

Creates and checks out a new branch named 

 based on the commit where the stash was created.

Applies the stashed changes to this new branch.

After executing this command, you will be on the new branch with your stashed changes ready to be committed.

Stashing without Affecting the Stash Reflog

In certain situations, you might need to create a stash without modifying the stash reflog. This can be useful in scripts where stashing is used as an implementation detail and you do not want these entries to pollute the visible stash list.

To create a stash without adding it to the stash list, use:

This command returns the object name of the stash entry, which you can use later if needed. For example:

If you decide later that you want to add this stash to your stash list, you can use the 

This adds the previously created stash to your stash list with a custom message, allowing you to manage it like any other stash.

By stashing your changes, you can keep your working directory clean and switch between tasks without losing progress. Whether you’re a novice or an experienced developer, mastering git stash is a valuable skill in your development toolkit. It can help maintain a clean and efficient workflow.

Stashing Changes in Git

Maintaining a clean and accurate commit history is crucial for managing versions and collaborating effectively.  One tool to achieve that is the 

 command, which allows you to amend the most recent commit. In this tutorial, we'll go through through how to use this command, when it’s appropriate to do so, and the implications of amending commits that have already been pushed to a remote repository.

Amending a commit is a straightforward process that modifies the most recent commit in your Git history. Here’s how you can do it:

: Edit, add, or delete files as needed for your project.

: Before you can amend the commit, you must stage the changes you wish to include. Use the 

: Once your changes are staged, you can amend the commit with the following command:This command opens your configured text editor to modify the commit message. If you don't want to change the commit message, you can simply save and close the editor.

 option which allows you to pass in a new message from the command line without being prompted to open an editor.

: If you’re happy with the original commit message and just need to change the content, you can use:

This will amend the commit without opening the editor.


Amending a commit should be used in specific situations to ensure the integrity of your commit history. Some appropriate scenarios include:

Correcting typos in your previous commit message

Adding small changes or files you forgot to include in your original commit

Adjusting the changes in your last commit before pushing to a remote repository

Amending commits that have already been pushed to a remote repository can complicate your project history, especially if others are collaborating on the same repository. Here are some implications and best practices:

: When you amend a commit, Git essentially replaces the old commit with a new one. This means the commit will have a new hash, making it a completely different entity in the eyes of Git.

: If you’ve already pushed a commit and then amend it, others who have pulled the original commit will encounter conflicts when pulling again. They will need to manually resolve these discrepancies, which can lead to confusion and errors.

: After amending a commit that has been pushed, you will need to force push to update the remote repository with the command:

However, use force pushing cautiously, as it can overwrite changes in the remote repository made by others.

Here are some best practices for amending commits:

 for changes that have been pushed to public branches, especially in collaborative projects.

: If you must amend a pushed commit, notify your team members about the change so they can adjust their local repositories accordingly.

 is a powerful tool for refining your commit history, it should be used judiciously to maintain the integrity of your project history, especially in collaborative environments. By understanding when and how to use this command, as well as the implications of amending pushed commits, you can effectively manage your Git repositories.

Amend last Commit with Git commit --amend

When working with Git, sometimes you may need to undo changes you've committed. Whether you've made a mistake in your last commit or just need to modify what was submitted, Git offers powerful tools to safely revert those changes. In this tutorial, we'll explore how to undo the last commit using 

How to Undo the Last Commit with 'git reset'

To undo the last commit in Git, you can use the 

 command. This command is versatile and allows you to reset your current HEAD to a specified state. To simply undo the last commit while keeping all changes in your working directory, you can use:

This command moves the HEAD, which is the pointer to the current branch, back by one commit, effectively making it as though the last commit never happened. However, it leaves your working directory and the index (staging area) as they were before you run the reset, allowing you to re-commit the changes if needed.

Difference Between 'git reset --soft' and 'git reset --hard

: This command is used when you want to keep all the changes in your working directory but reset the HEAD to a previous commit. For example, if you just want to undo the commit but not the changes you made, you can run:After running this command, the changes from the undone commit will remain in your staging area.

: This command is the most drastic form of reset. It completely undoes the commit and discards all changes in your working directory and staging area to match the state of the HEAD commit. Use this with caution because it cannot be reversed:

How to Revert a Commit Instead of Resetting It

Sometimes, you might want to undo a commit but keep its record in the repository's history. This is useful in collaborative projects where transparency is important. In such cases, you can use 

This command creates a new commit that undoes the changes made by the last commit. It is a safe way to undo changes that have already been pushed to a shared repository because it doesn't alter the project's history.

 when you are working with changes that have not been pushed to a shared repository. 

 is ideal for local undo operations where the changes have not yet been seen by others. It allows you to remove one or more commits from the current branch.

: If you notice a mistake in your last commit and want to fix or modify it before pushing it to a remote repository, 

 can be used to undo the last commit and re-commit the correct changes.

: Sometimes during development, you may want to clean up or consolidate your commit history before making it public. In such cases, 

 can help you shape your commit history before sharing it with others.

 for changes that have already been pushed to a shared repository or when working in a collaborative environment. 

 is safer for undoing changes that other people might have already pulled, as it doesn't alter the existing commit history.

: If it’s important to maintain a record of all changes (e.g., for audit purposes or regulatory reasons), 

 should be used. It creates a new commit that reverses the effect of earlier commits but keeps the project’s history intact.

 avoids conflicts that can arise from using 

 can rewrite commit history, it can lead to significant problems when other team members have based their work on the commits that are later reset.

Undoing the Last Commit in Git

In Git, the term "remote origin" refers to the default upstream repository that is associated with your local repository. It’s where your code is stored remotely, and it plays a crucial role in collaboration and version control in software development. There may be several reasons why you would need to change the remote origin URL of your Git repository. This tutorial will guide you through how to change the remote origin, explain why you might need to do it, and address common troubleshooting issues you might encounter.

Changing the remote origin URL in Git is a straightforward process that involves a few commands in your terminal or command prompt. Here are the steps:

Start by opening your terminal or command prompt.

Navigate to the directory of your local Git repository using the 

Before you change the remote origin, check the existing remote setup with 

. This command lists the remote connections you have to other repositories. Typically, you will see something like this:

 command followed by the name of the remote (usually "origin") and the new URL of the repository.

After changing the URL, verify the change by listing the remotes again:

You should see the URL updated to the new remote origin.

Reasons You Might Need to Change the Remote Origin

: You might be moving your project to a different repository host (from GitHub to GitLab, for example) or to a different account.

: The original repository might have changed ownership, and you need to update the remote URL to reflect this.

: In some cases, especially in complex projects, you might want to point to a different fork or a different branch temporarily.

: You might have initialized your repository with the wrong remote URL.

When changing remote origins, you might encounter some issues. Here are a few common ones and how to resolve them:

If you receive a permission denied error after changing the remote origin, it’s likely that you don’t have the correct access rights to the new repository. Ensure you have the right permissions, and that you are using the correct authentication method (SSH keys, username/password, etc.).

This error occurs if the URL is incorrect or the repository does not exist. Double-check the URL for any typos and verify that the repository exists at that URL.

After changing the remote origin, you might find that your branches do not line up with those in the new repository. Use 

 to update the branch information from the new repository and check the branches using 

Solving the "Remote Origin Already Exists" Error

If you encounter the "remote origin already exists" error while changing the remote origin in Git, there are several potential steps to resolve it. 

If there's already a remote called origin but it's incorrect, you can remove it and add the correct one. This scenario typically arises when switching between hosting platforms like GitHub and GitLab. Here's how:

Instead of removing and re-adding the remote, you can simply update its URL with a single command:

If you need to keep the old remote while adding a new one, you can rename the existing remote and then add the new one:

For example, you could rename your origin remote to new-origin like this:

There are other potential solutions to explore based on your specific situation. These include checking for typos in the remote URL, verifying your Git configuration, and ensuring proper authentication.

git Tutorials

Mastering Manual File Recovery: A Guide to Cherry-Picking Deleted Files

Navigating and Modifying Project History

Stashing Changes in Git

Amend last Commit with Git commit --amend

Undoing the Last Commit in Git

Changing the Remote Origin in Git

Practice Frontend, Android and iOS by building real world projects.