These rules and guides are written with git (a decentralised SCC system) in mind:
- commit = add changes to local repository
- push = sync changes with remote (central) repository

• Commit early, commit often
• Talk to the other developers to avoid editing files at the same time

  • this is especially true for binary files such as all LabVIEW files
• Implement and apply changes in your own feature branches, not in develop or master

  • use gitflow
• Use .gitignore settings

Meaningful branch names

• For naming, adhere to the format described here:

  • (Optional) start with the number (only the digits) of the issue that's addressed in this branch
  • An underscore (_)
  • A descriptive, but short and precise string

    • no capital letters
    • separate words with dash (-)
  • An underscore (_)
  • Your initials (first letter of surname, first two letters of last name)
• These rules apply also (and especially) if you're working with gitflow. Rules are to be applied to feature and hotfix branches.

• Examples:

  • 106_module-names-in-ui_mse
  • update-hse-libs_jha

• Try to avoid committing unfinished work (finish your train of thought)

  • Remember: Executable (no „broken VIs“) does not necessarily mean finished

• No broken code outside own feature branches

• No changes to develop branch without integration testing

Meaningful commit messages

• should summarize the changes done in one short sentence or a few words
• should work like a headline, so the history is more useful
• think of the commit message as the end to this sentence “If applied, this commit will your commit message here”
• Examples:

  • If applied, this commit will refactor subsystem X for readability
  • If applied, this commit will update getting started documentation
  • If applied, this commit will remove deprecated methods
  • If applied, this commit will release version 1.0.0
  • If applied, this commit will merge pull request #123 from user/branch

• Avoid committing project files unless you explicitly changed them (like adding another build or library), otherwise unnecessary merge conflicts may arise.
• Use project-specific .gitignore settings
• For FPGA: Stage only one FPGA main VI/bitfile per commit operation and add compilation results to commit message.