Those of you who are working as a programmer or a developer either in a team or going solo you must have used Git for version control. Cause who does not? Any smart person would want to have a safe backup of his/her projects and keeping track of the changes. For people working in a team, using Git version control is paramount for them. Now those of you who are new to programming world you should know what is git version control. After you know about it, you should learn some of the best practices of Git version control that are widely used throughout the programming community.
Best practices vary from context and situation, and there is no true answer, but still, this depicts an accord from Git and in some cases helps you build the discussion for the formation of your very own best practices. Although every team’s workflow is unique, some best practices stay fixed. Let’s take a look at a few of them:
Although every team’s workflow is unique, some best practices stay fixed. Let’s take a look at a few of them:
Make small commits and do it frequently
I believe it is one of the most important Git best practices. You should break up your work into multiple small tasks. Then start working each one of them. Git only takes responsibility for the work that you have committed. So for easier understanding, you should commit your work once you have completed your small target. Don’t do big commits. if you do, it makes it hard both to solve conflicts and to comprehend what happened Also do not commit unrelated changes together. Because small commits make it easier for other team members to understand the changes and roll them back if something went wrong. So 2 different bug fix should be done in 2 different commits.
Test before you push your commits
One of the things I always try to do and also paid the price of not doing is to test the change before commit. When you are working in a project when you think that the work is done you should check all the files that you have changed and check them thoroughly. If you are working in a team you would probably have some guidelines for code structuring like no commented code or indentation in a certain line etc. You should think about them too. As a Git best practice when you are fully satisfied that the code is working 100% and there is no code that violates the coding guideline then you should do the commit and push.
I know there is a lot of GUI application for Git. But you should try to use the terminal for Git. Although it seems counter-intuitive at first once you know the Git related commands you will feel that using terminal for Git is best. I personally use Git Bash. But you can use anything you are comfortable with.
The git command line serves to tell the user and keep errors out. Accessing Git’s documentation for a way commands are used is as straightforward as typewriting “man git” in Terminal. once commands fail, Git provides helpful messages and points out solutions. as an example, once the user tries unsuccessfully to push code to a remote repository, the failure message typically explains why git refused. the main branch may, for example, be missing commits that are on the remote branch.
Branching and Pull Request
Branching is one in all Git’s most powerful options – and this is often not by accident: fast and simple branching was a central requirement from day one. Branches are the proper tool to assist you to avoid mixing up totally different lines of development. you must use branches extensively in your development workflows: for brand new features, bug fixes, experiments, ideas.
A pull-request workflow promotes nice habits and provides protection. It consists of simply 2 basic steps. First, for each new feature, begin a brand new branch named subsequently feature. That way, the master branch stays untouched as you continue development. Knowing there’s no way to introduce bugs into the master engenders confidence and encourages experimentation. Then, once the branch is stable, create a pull request. If you’re working with others, this enables them to review your changes. If you’re on your own, it permits you to review a diff of the code within the branch. Once all problems are settled, merge the code into the repository.
Maintain a workflow
Git allows you to choose from plenty of different workflows: long-running branches, topic branches, merge or rebase, git-flow… which one you decide on depends on a handful of factors: your project, your overall development, and deployment workflows and (maybe most importantly) on your and your teammates’ personal preferences. but you decide onto work, just make certain to agree on standard progress that everybody follows
Use the useful commit message
Although I put this, at last, it does not mean it is less important. In face among Git best practices, it surely is one of the most important ones. Begin your message with a brief outline of your changes (up to fifty characters as a guideline). Separate it from the subsequent body by together with a blank line. The body of your message ought to give elaborate answers to the subsequent questions: What was the motivation for the change? however, will it disagree with the previous implementation? Use the imperative, tense („change“, not „changed“ or „changes“) to be according to generated messages from commands like git merge.
This is it for today. I’ll write more about Git later. In the mean time if you think you have some ideas on how Git should be used feel free to add it to the comment and I’ll update the post, so that everyone gets to learn new features.