Rules

For the simple use case, where you're working alone on a project; adding rules about how you work in DevOps only complicates the development cycle.

But, when you're going to collaborate with others, having rules is key to effective collaboration! 🚦

Git branches

Branches are defined, as such, by GitHub:

Use a branch to isolate development work without affecting other branches in the repository. Each repository has one default branch, and can have multiple other branches. You can merge a branch into another branch using a pull request.

-- GitHub Docs

We usually create a new branch from the main branch whenever we start on a new feature or try to solve an issue.
When we're happy with the changes we can merge the changes back into the main branch.

If, on the other hand, we're not happy with the changes; we can create a new branch from the main branch again and try something else.

We can freely switch between these branches, without losing the work we're doing in another (pretty useful when you're working on two features in parallel).

Pull requests

Pull requests are defined, as such, by GitHub:

Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.

-- GitHub Docs

Pull requests, often called PR, are used to merge branches into each other (usually a feature branch ➡️ main).
Merging can be done locally in Visual Studio Code, but doing it in Azure DevOps with the use of Pull Request allows others to review your work and comment on it. 💬✅

It's just more collaborative, and in some cases you actually don't have permission to modify the main branch directly (can be set in the branch permissions page on Azure DevOps) — forcing you to use a PR. 🔐

Be a gentleman 🎩

So, please follow the following rules when working on other people's projects:

1. Clone the repository
2. Switch to the main branch
   • Consult the project owner if there's no branch called main (they've called it something else).
3. Pull the latest changes
   • Make it a habit to click that refresh button in the bottom-left corner in Visual Studio Code, to make sure you never miss any changes that others have made.
4. Create a new feature branch
   • Give it a simple name, in all lowercase and underscores separating words, for instance: feature_auto_create_order.
5. Make your changes
   • Make frequent commits, preferably with small changes, and write your commit messages in this style. 👈 READ IT!
   • Push your commits as you make them, to not lose your work.
6. Create a pull request in Azure DevOps
   • Make sure you select the correct target and source branches (source is your feature branch, target is main).
   • Add any reviewers if required.
7. Wait for the project owner to review, approve and complete the PR
   • They control the merging, you just have to answer their comments and make changes accordingly.
   • Make the changes directly in the feature branch — as you push more commits, the PR gets updated automatically.