"Ah!! Plenty of articles here on the git, I don't want another one." - My first reaction when I reviewed this before publishing. 😜
Well, we as a team follow a predefined set of rules before committing codebase in git. I'm sharing the same over here as I find them very promising in order to maintain git sanity.
- Your code is formatted. (let me know in comments if you are also suffering from this phobia 😧 ).
- Don't you dare committing an erroneous code. 😈👿
- Don't forget to update your README.md regularly with required updates on each commit. You may wish to have a look at this article.
- Commit Message must start with Jira ticket number(i.e. XYZ-1234).
- The second word of commit message must be either of (added, removed, changed, refactored, corrected).
- Nobody commits on master and feature/parent branch.
Extensions and Utilities:
I would strongly suggest you to configure,
- Configure GitHub with Jenkins, which would help you trigger automated Jenkins builds upon committing to GitHub
- Configure GitHub with Sonar Qube, which would trigger Code Review upon pushing any code in GitHub
- GitHub with Jira, which would help you check progress(commit logs) on Jira
Rules while creating new Repository:
This will be default structure for any new repository to be created in Production.
- Master will contain only README.md
- Release will be passed via feature/parent branch only.
- feature/develop and feature/fixes will be merged into feature/parent only when the code is reviewed
- All new branches will be extension of develop branch only
- Need new Repo?: Create as much as you want, but keep em private only.
- Default collaboration: only to required people
As usual, suggestions are always welcomed. Happy Coding and may the code bless you. 😇
Top comments (4)
Your commit message rules conflict with the tradition of using the imperative tense, and it doesn't seem like your rules would be incompatible with following the tradition.
E.g. by convention your commit messages should work with this format: "If applied, this commit will: your commit message here". So you would write "Add feature XYZ" or "Fix login issue on page ABC" as the initial line of the commit message and it would work with that format.
In your case you could just change the tense of your second-word rule, "add", "remove", "change" etc.
Is there any reason why you went this route? Either version conveys the same information, both are just as grep-able, but only one follows convention.
Also notice that this is the style for merges, eg.
Merge pull request #300...so even if you're just staying consistent with the automatically generated messages it's important.Exactly, your commit message should be in the imperative mode.
Thank you, most people on my team write in past-tense :(