Why are we doing this?
TFS is slow.
Better support for branching and merging.
How to prepare
Send me your github credentials.
Install a git client.
How will the old TFS branches map to git
- Dev → develop
-
new features for Dev → feature/name
- Main → release/futuredate
-
hotfixes for Main → hotfix/name
- Release111213 → release/20131112
-
hotfixes for Release111213 → hotfix/name
Conventions
Format of the commit message
[type]([scope]): [subject]
[BLANK LINE]
[body]
[BLANK LINE]
[footer]
Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on github as well as in various git tools.
Subject line
Subject line contains succinct description of the change.
[type]([scope]): [subject]
Allowed [type]
-
feat: A new feature
-
fix: A bug fix
-
docs: Documentation-only changes
-
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
-
refactor: A code change that neither fixes a bug or adds a feature
-
perf: A code change that improves performance
-
test: Adding missing tests
-
chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
Subject line (cont.)
[type]([scope]): [subject]
Allowed [scope]
Scope could be anything specifying place of the commit change. e.g. EnterpriseApi, PASS, Domain, PlatformServices, etc...
[subject] text
- use imperative, present tense: “change” not “changed” nor “changes”
- don't capitalize first letter
- no dot (.) at the end
Message body
just as in [subject] use imperative, present tense: “change” not “changed” nor “changes”
includes motivation for the change and contrasts with previous behavior
Message footer
Breaking changes
All breaking changes have to be mentioned in footer with the description of the change, justification and migration notes
Who to talk to when things go south