Git best practices #BackToBasics

Git has taken source control systems to a new era. I have started my career with Subversion but eventually moved to git. Following are some of the practices which helped me to manage my code well. Most of these are basic guidelines but while listing them here I have realized I am skipping some of them. Its always good have a relook at basics :).

These git basic practices are like TDD and Agile which everyone know but miss practicing because of various reasons which I would leave it to reader ;).

Branching practices

  • Pick a branching model, which can make sure
    • Developer can switch working on diff features easily. It shouldn’t be like commenting code while you are working on a feature, if you needed to work on something else.
    • One place where features developed by teammates can be merged and tested
    • One branch which always contains code running in production so that we can fix production issues immediately
    • Can accommodate multiple teams with different deadlines to collaborate
  • Create branch for every story which might take more than half day. Instead of asking “why a new branch?” lets ask “why not a new branch?”. If not enough reason, go ahead create a branch.
  • Do clean/delete the branch once done with that feature.
  • Name branch with issue number if you are using any backlog tool. This is helpful for team member to quickly see which branch is for what.

Git commits

  • Try not to use “git add .”. Add one file at a time after checking diff
  • Regular committs will make sure you have less files to check and commit
  • Make sure your commit message contains issue number you are working on.
  • Commit ONLY related files together
  • Have your .ignore file updated with all files which need not be committed. When we type “git status”, we shouldn’t see any file which is yet to be committed. Sometimes this needs some work in code to make sure local profile is available.
  • Tag commits with releases, major milestones


  • git is for source code not for binary files. Do not check-in artifacts. Make use platform specific distribution strategy.
  • If you need a minor change in repository of another team, instead of sending mail with lines of code to update, make change and send a pull request
  • At least every day/half day, pull changes from integration branch

Repository level

  • If a project is started after successful POC, create a new repository for project instead of reusing PoC repository
  • Make sure all repositories are in one of the related organization but not under personal repos
  • Sometimes based on context and team structure, you might like to have different repositories for different components. Especially when some of the components are shared components.
  • Its always good to give enough thought to give a good name to repository. Name of the repo should give quick glimpse of what it contains. Avoid acronyms unless they are famous. No need to include portfolio name as organization already reflects it.
  • file is MUST with
    • Some description about project
    • URLs for the application
    • Important contacts
    • Servers used by code in this repo
    • Documentation link
  • Any code (code in artifact, properties, config etc) must be in source control.

The biggest myth of quality code : 100% Test coverage

How many of you believe you have quality code because you have good test coverage? Or how many of you feel you are working with bad quality legacy code because it doesn’t have any test coverage? Recently every organization started focusing on quality especially automation. Started putting people to increase unit test coverage. But did you question : Did you gain anything out of it? Is your code quality improved? How long these test cases will be relevant ? Do you think developers would be comfortable modifying it when code changing?

Continue reading

For God’s sake, “keep it simple”

If someone asks me what is the best practice to finish a software project successfully, I say “Keep it simple”. Well you heard it many times. But actually did you follow it. In fact its quite simple to keep things once you leave your ego and selfish thoughts away. If you think I am just bullshitting I can make you agree by the end of this blog. Continue reading

Common mistakes made in Agile projects based on new technologies : Xebia Blog

“In recent times Agile methodology have proved its worth by successfully executing the projects. It minimizes the risk by developing software in short amounts of time. With this iterative model it also minimizes the cost of change in requirements, which makes it suitable for current dyanmic market. Two main practices that helps the developer to incorporate the change are refactoring and simple design. But when it comes to doing these two things with a completely new technology, it might be hard to implement.

In this article I am going to share some of my experiences with my first project. This is an agile project based on a technology which is new to the whole team. I spent around two weeks in understanding the technical features and strengths of the technology.Where as others in the team had never worked with it or similar technology. Here I will discuss about some mistakes that ( I feel 😉 )we did while executing the project. “