Hacks that Simplified My Local Git Repository

Dear Developers,

most of our time goes to working with Git commands. It’s a lot of “git this, git that,” right? I believe repetitive work should take as little effort and time as possible. That’s why I think it’s essential to spend a bit of time setting up our Git repository to run smoothly. In this blog, I’m sharing some of the hacks I’ve used to keep my local Git repo simple, organized, and efficient. These are small steps, but can save loads of time and hassle in the long run.

I Don’t Want to Type the git commit -m "message" Every Time

When you’re working with Git, committing changes becomes a regular task. But if you find yourself repeatedly typing out the same git commit -m "message" command for every commit, it can start to feel like a chore. Wouldn’t it be great if we could make this simpler?

Solution: Git Aliases

One of the easiest ways to make Git commands more efficient is through Git aliases. Aliases allow you to shorten commands and avoid repetitive typing, making your workflow much faster.

In this case, instead of typing git commit -m "message" every time, we can create an alias to simplify it. we can make this change in our .gitconfig file which you can find in your root directory.

Rajat.Singh@QQ0KRXJQ91 ~ % cat .gitconfig                          
[user]
        name = Rajat.Singh
        email = mailtorajatsingh@gmail.com
[alias]
        co = commit -m
        status-java = status -- '*.java'
        st = status
                

or you can execute the below command to achieve the same

git config --global alias.co "commit -m"
        

Now, whenever you want to make a commit, you can just run:

git co "Your commit message here"
        

This shorthand saves you from writing out git commit -m each time.

Other Useful Git Aliases

Git aliases can be set for almost any command, and you can customize them to suit your workflow. Here are some common aliases that can make your Git experience smoother:

1. git st for git status
2. git br for git branch
3. git lg for a More Visual Log
4. git last for the Last Commit
5. git undo for git reset --soft HEAD~1
6. git amend for git commit --amend

Problem: I Don’t Want Certain Files to Show Up in git status

Sometimes, you have files in your Git repository that you never intend to commit—like configuration files or build scripts.

Yet, when you run git status, these files keep showing up as "modified," even though they aren’t meant to be shared or committed.

Is there a way to ignore these files so that our repository looks clean and shows only the files we want to commit?

(Not a) Solution: Using .gitignore

If Git is not already tracking these files, you can simply add them to a .gitignore file, which will prevent them from appearing in git status. However, if Git is already tracking these files, adding them to .gitignore won’t help because Git will continue monitoring any changes. You first need to "untrack" these files to remove them from Git’s radar:

git rm --cached <file-name>
git commit -m "recently Untracked files to clean up repository"        

But be careful! Running this command will remove the files from the repository in the next commit, which may not be what you want if the files should stay in your local working directory.

The Real Trick: Ignoring Files Local-Only

let's keep certain files only in your local repository without showing up in git status.

When you modify a tracked file, Git compares the file content in your working directory with what’s stored in the "index" (the staging area) or the last commit. If there are any differences, Git marks the file as modified.

Solution: Telling Git to Ignore Local Changes

Now that we know the Git index tracks changes, we can tell it to “relax” and ignore local modifications for specific files. Here’s how to do it:

1. Skip Worktree: This tells Git to stop tracking changes for a specific file, even if it’s already being tracked.

git update-index --skip-worktree <file-name>        

2. Assume Unchanged: This option will mark the file as unchanged, keeping it out of future git status checks.

git update-index --no-assume-unchanged <file-name>        

These commands update Git’s internal settings, allowing you to keep local-only changes without them appearing in git status. Now, you can have a cleaner repository with only the files you truly want to commit!

Problem: Handling a Production Bug Without Losing Current Work

Imagine you’re working on a feature branch, making several changes to files that aren’t yet committed. Suddenly, a production bug pops up that needs immediate attention! You don’t want to commit your incomplete work just to switch to another branch—so what do you do?

Solution: Using Git worktrees to switch Multiple Branches without losing current work

With Git Worktree, you can create multiple working directories linked to the same Git repository. This means you can have a different branch in each directory, allowing you to work on the production fix while keeping your current changes untouched. No stashing, no temporary commits—just a clean, organized way to switch tasks without hassle.

Here’s how to set it up:

1. Create a New Worktree for the Production Branch

First, use the following command to create a new directory (worktree) and check out your production branch there:

git worktree add ../production-fix-branch production        

• This command creates a new folder named production-fix-branch outside your current working directory.
• Inside this folder, Git will check out the production branch, so you can work on the bug fix without touching the changes in your current directory.

2. Navigate to the New Worktree Directory

After creating the worktree, you can switch to the new directory and start working on the production bug immediately. Any changes you make in this worktree won’t affect your original working directory, so you can safely debug, commit, and even push your fix.

cd ../production-fix-branch        

3. Return to Your Feature Branch Work

Once you’ve fixed the production bug, committed, and pushed the changes, you can return to your original worktree by switching directories back to where your feature branch is located:

cd ../your-feature-branch-directory        

Now, you’re back to your original branch with all your uncommitted changes intact, just as you left them!

Thanks for Reading.