Dev:Git Guidelines
Tips for making good commits
Never commit code that doesn't validate
Validate the code (XSD-files) and examples (XML-files) together. Correct all errors before committing. Make sure that newly added files are committed. If they are missing, your local validation will work fine, but everybody else won't be able to validate without errors.
Double check what you commit
Do a repository update and a repository diff before committing. Take messages from repository about conflicts, unknown files, etc. seriously. A repository diff will tell you exactly what you will be committing. Check if that's really what you intended to commit.
Always add descriptive log messages
Log messages should be understandable to someone who sees only the log. They shouldn't depend on information outside the context of the commit. Try to put the log messages only to those files which are really affected by the change described in the log message. In particular put all important information which can't be seen from the diff in the log message.
Respect other coordinator's code
Consult other developers before making large changes. Source control systems are not a substitute for developer communication.
Announce changes in advance
When you plan to make changes which affect a lot of different code in the repository, announce them in the newsgroup in advance. By announcing the changes in advance, developers are prepared, and can express concerns before something gets broken.
Take responsibility for your commits
If your commit breaks something or has side effects on other code, take the responsibility to fix or help fix the problems.
Don't commit code you don't understand
Avoid things like "I'm not completely sure if that's right, but at least it works for me." If you don't find a solution to a problem, discuss it with other developers.
Don't commit if other developers disagree
If there are disagreements over code changes, these should be resolved by discussing them in the newsgroup or in private (e-mail or phone), not by forcing code on others by simply committing the changes to the repository.
Backport bugfixes
If you commit bugfixes, consider porting the fixes to other branches. Use the same comment for both the original fix and the backport, that way it is easy to see which fixes have been backported< already.
Tags and branches
Official railML branches and release tags will be created by the release coordinator in the branches/ and tags/ directories. All temporary working branches (which should be deleted again after the work has ended) should be located in branches/ with some name describing both which part of railML is branched and which work is done there, e.g. branches/timetable-duty.
Don't use repository keywords in source files
Repository keywords like Id or Log cause unnecessary conflicts when merging branches and don't contain any information which wouldn't be available in the repository anyway.
Make "atomic" commits
Repository has the ability to commit more than one file at a time. Therefore, please commit all related changes in multiple files, even if they span over multiple directories at the same time in the same commit. This way, you ensure that the repository stays in a validable state before and after the commit. Consider changing example files in the repository.
Don't mix formatting changes with code changes
Changing formatting like indenting or white spaces blows up the diff, so that it is hard to find code changes if they are mixed with re-indenting commits or similar things when looking at the logs and diffs later. Committing formatting changes separately solves this problem.
Have a clear commit message
Honoring Dev:Coding_XML_Components and Dev:Syntactic_Guidelines, write commit messages in English. The first line of commit is a summary of the changes. The rest of the message should give more details on the change as appropriate. Give credit where credit is due.
Review process
Commits are reviewed by the railML coordinators. In case of commits, non-conformant with these guidelines, railML coordinators have to fix the situation with a commit indicating the correction in the log message.
Some paragraphs are adopted from KDE TechBase Wiki (external link), maintained by Cornelius Schumacher (external link).