Hi! I'm back with the second part of this series. Sorry for the delay. I don't have a lot of experience writing posts, and it takes me a moment. 😆 In this post, I want to share more cool Git commands and use cases inspired by my experience. I hope you enjoy it!

By the way, I generated an image for the post with Mistral to have a cool banner picture. 😅 Let me know what you think!

Git stash

The git stash command is incredibly useful when you need to switch contexts but don't want to commit your current changes. It allows you to save your changes temporarily and come back to them later.

# Stash your current changes
$ git stash

# List all stashes
$ git stash list

# Apply the most recent stash
$ git stash apply

# Apply a specific stash
$ git stash apply stash@{1}

# Drop the most recent stash
$ git stash drop

# Drop a specific stash
$ git stash drop stash@{1}

# Clear all stashes
$ git stash clear

Git cherry-pick

Sometimes, you might want to apply a specific commit from one branch to another. The git cherry-pick command allows you to do just that.

# Cherry-pick a specific commit
$ git cherry-pick 

# Cherry-pick a range of commits
$ git cherry-pick ^..

Git bisect

git bisect is a powerful tool for finding the commit that introduced a bug. It uses a binary search algorithm to help you identify the problematic commit efficiently.

# Start bisecting
$ git bisect start

# Mark the current commit as bad
$ git bisect bad

# Mark a known good commit
$ git bisect good 

# Git will check out a commit in the middle. Test it and mark it as good or bad.
$ git bisect good  # or
$ git bisect bad

# Continue this process until Git finds the first bad commit.

# Reset bisecting
$ git bisect reset

Git tag

Tagging is useful for marking specific points in your repository’s history as important. Typically, this is used to mark release points (e.g., v1.0.0).

# Create a lightweight tag
$ git tag 

# Create an annotated tag
$ git tag -a  -m "Tag message"

# Push a tag to the remote repository
$ git push origin 

# Push all tags to the remote repository
$ git push --tags

# List all tags
$ git tag

# Delete a local tag
$ git tag -d 

# Delete a remote tag
$ git push origin :refs/tags/

Git diff

The git diff command shows the differences between commits, branches, files, and more. It’s a crucial tool for understanding what changes have been made.

# Show changes in the working directory that are not yet staged
$ git diff

# Show changes between the index and the last commit
$ git diff --cached

# Show changes between two commits
$ git diff  

# Show changes between two branches
$ git diff  

# Show changes in a specific file
$ git diff

Git blame

The git blame command annotates each line in the given file with information about the last modification. This can be helpful for understanding who made specific changes and when.

# Show the last modification for each line of a file
$ git blame 

# Show the last modification for each line of a file at a specific commit
$ git blame  --

Git commit --amend

The git commit --amend command is a lifesaver when you need to make changes to your most recent commit. Whether you forgot to add a file, made a typo in the commit message, or need to adjust the changes, --amend allows you to modify the last commit without creating a new one.

Use Cases

  1. Fixing Commit Messages: If you realize you made a typo or want to provide more context in your commit message, you can amend it.
  2. Adding Forgotten Files: If you forgot to add a file to the last commit, you can stage it and amend the commit to include it.
  3. Modifying Changes: If you need to make minor adjustments to the changes in the last commit, you can do so and amend the commit.

How to Use 

# Make your changes (e.g., edit files, add new files)
$ git add 

# Amend the last commit
$ git commit --amend

When you run git commit --amend, your default text editor will open with the previous commit message. You can edit the message if needed, save, and close the editor. The commit will be updated with your changes.

Important Notes

  • Avoid Amending Published Commits: If the commit you want to amend has already been pushed to a shared repository, avoid using -amend. Amending a published commit can rewrite history and cause issues for others who have based their work on the original commit.
  • Force Push: If you must amend a published commit, you will need to force push the changes to the remote repository. Be cautious with this, as it can overwrite history. 
# Force push the amended commit
$ git push --force

Saving Disk Space with git clone --depth=1

When working with large repsitories, cloning the entire history can consume a significant amount of disk space. Fortunately, Git provides a way to clone only the latest commit, which can save you a lot of space and time. This is particularly useful when you only need the most recent version of the code.

Use Case

  • Large Repositories: If you're working with a repository that has a long history and many large files, cloning the entire history can be time-consuming and disk-intensive.
  • CI/CD Pipelines: In continuous integration and deployment pipelines, you often only need the latest code to build and test. Cloning the entire history is unnecessary and can slow down the process.

How to Use

The --depth option in git clone allows you to specify how many commits you want to clone. Setting --depth=1 clones only the latest commit.

# Clone only the latest commit of a repository
$ git clone  --depth=1

Important Notes

  • Shallow Clones: Cloning with -depth=1 creates a shallow clone. This means you won't have the full history of the repository, which can limit some Git operations that rely on the complete history.
  • Fetching More History: If you later decide you need more history, you can fetch additional commits using the git fetch command with the -depth option. 
# Fetch more history (e.g., the last 10 commits)
$ git fetch --depth=10
  • Unshallowing: If you need to convert a shallow clone to a full clone, you can use the git fetch --unshallow command. 
# Convert a shallow clone to a full clone
$ git fetch --unshallow

Conclusion

I tried to cover real-world scenario examples from my experience to show you some of Git's tools that can be useful. In the next and final post of this series, I will talk about workflows and more real-world use cases. I'm looking forward to your comments and I hope you've learned something! If you have any recommendations or corrections, please let me know!

Thanks for reading, and see you next time!