Commit messages guide
This is one of those interesting bits where things feel more like personality types as opposed to ways to create maintainable software. I have yet to see a project fail because commit messages were or were not in imperative form or if the first letter was capitalized. I have no problem doing it if someone in the team finds it important, and I have no issue if someone on the team does not do it.<p>The same is generally true about rebasing etc.<p>Due to the high visibility of commit messages, a lot of details certainly look pretty bike shed-ish.<p>What can be important is simply a general concept of meaningful messages when they make sense. For example, bug fixes that may not be obvious by looking at the code, should probably have a reasonably detailed description of the bug. Commits implementing a brand new feature and involving a ton of changes, probably don't need a whole lot more than what the feature is and what is the expected behavior. Possibly some info about potential future bugs that could happen. When updating the readme, "Updating documentation" is just fine plenty of times.<p>Otherwise, probably just make sure you include some important keywords to make it easier for people to git-grep and I think most projects will be just fine.<p>There ar certain personality types that really enjoy organization and rules. And the feeling of security that comes from having a well defined set of procedures everyone must follow. It really isn't about making software more maintainable based on any existing research we have about how maintainable software is. But if it benefits some of my coworkers mental health by following those rules, it really doesn't take me any additional effort to follow those rules so I have no problem doing it.