While there are no coding conventions per se, you can, if you wish include commenting to explain changes, though, after approval and merging they may be removed to save space, but comments acknowledging changes added to the header block comment. However, generally, we try to build code in such a way that it's easy to work out what the code is achieving, but overall, we are more interested in writing code in such a way that it runs fast. This usually includes removing white spaces with code itself, but formatting the code with tabs, more so, for readability.
v[full].[release].[patch]
[full] is a release that has it's features frozen, and can sometimes be a full version, and precursor to major changes.
[release] number is where releases are published when [patch] reaches a point where features are full implemented.
[patch] are repository updates, which I am now looking at doing more often for backup purposes, so we don't have one place where changes have been made and don't exist anywhere else. When patches have features or major fixes are complete, we can move to a [release] publish. This way there will be less releases, but better fixed or feature rich release.