This repository contains an overview of the tools and the technologies we are using for the summer internship projects.
Technologies used:
Tools used:
- Aha! (product roadmap)
- Slack (irc/chat)
- Git (version control)
- GitHub (code reviews)
- Visual Studio Code (editor)
- Waffle (project management)
- Visual Studio AppCenter (CI/CD)
- Visual Studio 2017 Community Edition (IDE)
If you are familiar with some of the tools/technologies, that's great. If not, start skimming through the links under "general information". Second, consider installing Windows 10 on your machine as Dualog is heavily connected to the .NET / Microsoft ecosystem. Having a decent Mac with VS Code and VS 2017 for Mac installed will get you far, too.
Some standards that we follow within the Organization, this is to keep the development process somewhat streamlined.
Coding conventions create a consistent look to the code, so that readers can focus on content, not layout. They enable readers to understand the code quicker by making assumptions based on previous experience. They also facilitate copying, changing, and maintaining the code.
To achieve this we are using an EditorConfig inside each project. EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs. The EditorConfig project consists of a file format for defining coding styles and a collection of text editor plugins that enable editors to read the file format and adhere to defined styles. EditorConfig files are readable and they work nicely with version control systems.
See this link for .NET coding convention settings examples for editorconfigs.
All Git Commit Messages should meet the following text format:
Subject line
(One newline)
Message Body
(One newline)
Ref <###>
- Capitalize the Subject.
- Do not end the Subject line with a period.
- Message Body should end with at least one issue tracking reference.
- Use valid MarkDown in the message body.
- Use the present tense ("Add feature" not "Added feature").
- Use the imperative mood ("Move cursor to..." not "Moves cursor to...").
- Use the message body to explain what and why vs. how.
Refer to an issue describing the bug when fixing bugs.
Remember: Since we are using Waffle.io you should always append "#isseNumber" to the branch name, this automatically moves your issue in the kanban board.
Info: Master and development branches are always protected, so you can't push directly to them
| Naming | When to use? |
|---|---|
feature/awesome-branch-name |
When developing a new feature |
bugfix/awesome-branch-name |
When fixing a bug |
hotfix/awesome-branch-name |
When fixing an urgent bug |
docs/awesome-branch-name |
When updating documentation |
tooling/awesome-branch-name |
When changing tooling |
performance/awesome-branch-name |
When improving performance |
refactoring/awesome-branch-name |
When refactoring code |
cosmetic/awesome-branch-name |
When improving UI/Cosmetic |
testing/awesomest-branch-name |
When adding tests |
See GitHub workflow for further explanation.
When creating a new feature, you should branch off from development and create your own branch.
E.g.
git checkout development
git pull
git checkout -b feature/awesome-new-featureTry to commit your changes as you go, but commit with logical steps. This will make it easier when team-members are reviewing your code.
git add relevant-code
git commit -m "Nice commit message that follows commit-message rules"If others have pushed changes to the development branch you can apply those changes to your branch by rebasing the branch into yours and solve any eventual conflicts locally. (git checkout feature/awesome-new-feature && git rebase development)
If you have commits and you are not pleased with their commit messages, now is a good time to stop and fix them. Rebase your own branch by git rebase -i HEAD^n going n commits back and you'll be able to edit, squash or fixup your commits before pushing. If the last commit message is unsatisfactory you can use git commit --amend.
Push your changes to GitHub by
git push -u origin feature/awesome-new-featureor do git push if you're already tracking a remote branch.
You can now create a pull request on GitHub from your branch into development.
Once the branch has been merged into development you can delete your local branch by git branch -D feature/awesome-new-feature. Make sure to delete the remote branch after it has been merged. This is done through the browser on GitHub or by using
git push -u -d origin feature/awesome-new-featureAll the repositories made in the "Dualog-Students" organization starts as open-source and licensed project by project. Dualog can at any time decide to take an open-source project and close it from the public to either hide company secrets or for protecting customers. See https://choosealicense.com/ for open-source licensing examples.