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
Collaboration
- 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.
- README.md 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.
Ganesh's Blog 