Git -Best practices

git- best practices

Git -Best practices

Why use Git? What are the pain points that we face from our experience? why should we be using few best practices in git

                    Git is a version control system (VCS) for tracking changes in computer files and coordinating work on those files among multiple people. It is primarily used for source code management in software development, MVP development but it can be used to keep track of changes in any set of files. As a distributed revision control system it is aimed at speed, data integrity, and support for distributed, non-linear workflows. These can be achieved only  by using the best practoces in git

Git is a free and open source version control system, originally created by Linus Torvalds in 2005. Unlike older centralized version control systems such as SVN and CVS, GIT is distributed: every developer has the full history of their code repository locally. This makes the initial clone of the repository slower, but subsequent operations such as commit, blame, diff, merge, and log dramatically faster.

Git also offers an excellent support for branching, merging, and rewriting repository history, which leads to several innovative and powerful workflows and tools. Pull requests are one such popular tool that allows teams to collaborate on GIT branches and efficiently review each other’s code. In the current trend, GIT is the most widely used version control system and considered as the modern standard for software/ product development.

Best practices in git: Ensure to make use of

  1. Ensure to make use of the accurate name and email id information in GIT Config.
  • Only one of the team member must initialize the GIT
  • Other members should not use make use of the same config. They need to tweak the config.
  • If the same config is used by all the team members, it will be difficult to track the changes made as the same name will appear for every change made. Hence, uniqueness of config is mandatory
  1. Push it soon (big changes vs small changes).
  • Irrespective of sort of changes may be small or big, Be it a small change or a big change practice to push it as soon as it is made
  • Delays in push of changes may lead you to get confused
  • Similarly, if many people are involved in a project, it becomes tough to push changes to the server as everyone will come up with small or big changes.
  1. Never put broken code on the master branch (test first!).
  • If there is existence of issues with a code while in the working phase, it is not advisable to put such changes in the live project as it will lead to trouble in mere future.
  • Always, it is recommended to ensure that all codes you are planning to push it to the main server passes all the tests.
  1. Break-up the work you are doing
  • It is vital to manage your work properly as it is not good to perform two week’s work in one.
  • Even if it is a minor change, it is best to push it first to the server prior continuing the next change. As if you fail to do so, all such small changes will get piled up and transform into a huge and confusing big change to deal.
  • Also, if more than a person works on a code in a same module, there is more probability for arising of conflict which requires additional time to get resolved.
  1. Always use a clear, concise commit message.
  • Commit message indicates that changes had been made in the particular module or work
  • So this has to be very clear stating clearly the changes in a easy and understandable manner unless it becomes ineffective.
  1. Put more details in the lines below, but always make the first line short.
  • The first line of the commit message should be very clear specifying the changes made which should be short and precise to the point.
  • The lines below must be written specifying the supporting facts.
  1. Describe the why; the what clearly in the change log.
  • This is an added advantage
  • Each member can maintain his or her own change log so that even if there is some confusion or misunderstanding, it becomes easy to sort it out using the backup change history.

Conclusion

 

It becomes easy with GIT to track changes made in a file especially when it is being handled by multiple hands. Also, it is good to always maintain a change log as in the case of any necessity to track the modifications made, this GIT will throw lights on the issue. Using the latest largely used version control system GIT, have a complete control on your software tools and workflows.

© Siam Computing , Crafted in Chennai