Tag Archives: git


Ignore changes to an existing file in a git repo

It frequently happens to me that I want to ignore changes to an existing file in a git repo. Or put otherwise, don’t track changes for a specific file.

Obviously you can use a strategy where you would commit a file with a suffix like config.rb.example or web.config.dist. And .gitignore the actual ones. But this is suited ideally for config files which only requires a onetime setup. Personally, I find it quite convenient to ignore changes to be able to toggle tracking changes to a specific file. For this purpose you might want to pull up your sleeves for the following git commands.

Ignoring all changes to a specific file:

git update-index --assume-unchanged <path_to_file>

And this is easily reverted, where you can use the no-assume-unchanged command to enable tracking of changes again:

git update-index --no-assume-unchanged <path_to_file>

Perfectly sane. But these changes will live on throughout the lifespan of your current branch. And it might be likely that someday you’ll forget what files exactly were ignored in your repo. When this happens you can use the following command to list all changed, untracked files:

git ls-files -v | grep '^[[:lower:]]'

A final important notice is that when you have made changes to a file that is untracked and you decide to switch branches, you might run into the following error:

error: Your local changes to the following files would be overwritten by checkout: … Please, commit your changes or stash them before you can switch branches.

The error message git spits out is quite self explanatory; you have to decide either to commit or discard the changes before switching branches.


Best Practices of Version Control

Always use version control. Always… There really is no excuse why you shouldn’t use some form of version control. Not even when you’re a one man army.

I prefer git myself, but all versioning systems have their own advantages, depending on your specific need and competences of your team members. The list below is a uniform cheatsheet for best practices on version control, and was originally setup by the people from Tower.

1. Commit Related Changes

A commit should be a wrapper for related changes. For example, fixing two different bugs should produce two separate commits. Small commits make it easier for other developers to understand the changes and roll them back if something went wrong. With tools like the staging area and the ability to stage only parts of a file, Git makes it easy to create very granular commits.  

2. Commit Often

Committing often keeps your commits small and, again, helps you commit only related changes. Moreover, it allows you to share your code more frequently with others. Sharing is a good thing. That way it’s easier for everyone to integrate changes regularly and avoid having merge conflicts. Having few large commits and sharing them rarely, in contrast, makes it hard to solve conflicts.  

3. Don’t Commit Half-Done Work

You don’t leave the toilet until the job is done. Neither should you commit code until it’s completed. This doesn’t mean you have to complete a whole, large feature before committing. Quite the contrary: split the feature’s implementation into logical chunks and remember to commit early and often. But don’t commit just to have something in the repository before leaving the office at the end of the day. If you’re tempted to commit just because you need a clean working copy (to check out a branch, pull in changes, etc.) consider using Git’s “Stash” feature instead.  

4. Test Before You Commit

Resist the temptation to commit something that you “think” is completed. Test it thoroughly to make sure it really is completed and has no side effects (as far as one can tell). I always ask myself: “Will it blend?” While committing half-baked things in your local repository only requires you to forgive yourself, having your code tested is even more important when it comes to pushing / sharing your code with others. Really, test it – then test it again!

5. Write Good Commit Messages

Begin your message with a short summary of your changes (up to 50 characters as a guideline). Separate it from the following body by including a blank line. The body of your message should provide detailed answers to the following questions: What was the motivation for the change? How does it differ from the previous implementation? Use the imperative, present tense (“change”, not “changed” or “changes”) to be consistent with generated messages from commands like git merge.

6. Version Control is not a Backup System

Having your files backed up on a remote server is a nice side effect of having a version control system. But you should not use your VCS like it was a backup system. When doing version control, you should pay attention to committing semantically (see “related changes”) – you shouldn’t just cram in files.  

7. Use Branches

Branching is one of Git’s most powerful features – and this is not by accident: quick and easy branching was a central requirement from day one. Branches are the perfect tool to help you avoid mixing up different lines of development. You should use branches extensively in your development workflows: for new features, bug fixes, ideas…  

8. Agree on a Workflow

Git lets you pick from a lot of different workflows: long-running branches, topic branches, merge or rebase, git-flow… Which one you choose depends on a couple of factors: your project, your overall development and deployment workflows and (maybe most importantly) on your and your teammates’ personal preferences. However you choose to work, just make sure to agree on a common workflow that everyone follows.

Credits and much more elaborate tips and trics for this article go to Git Tower.