Azure-in-bullet-points

Using git

• You can use git cli
• You can also use other tools such as Visual Studio (through Team Explorer)
  • Connect directly to Azure DevOps with your Microsoft account to work with Azure Repos.

Git CLI

• Create a repository
  1. Download git
  2. run git init on a folder where you’ll want to have your repository
     • You get master branch ready
     • HEAD shows the current branch in start it’s master
  3. Create a file called filename.txt
  4. Run git add filename.txt or git add . (for all files in the folder)
  5. Commit your changes with a message git commit -m "first commit"
• Useful commands
  • git log: to show all commits
    • Each commit has SHA hash you can see here.
    • You can revert a commit using git revert commit-sha (or first 3 chars of the sha)
  • git fetch: to download remote-tracking branches
  • git pull: does git fetch followed by a git merge FETCH_HEAD to update your files to latest in remote.

Branching

• Working with multiple developers -> Changing master branch is not good.
  • Some changes may not be complete or working as it should.
  • Making changes to master branch itself can make other developers get incorrect or non-working code.
• Instead create another branch from master and each developer work on their own branches
  • Main master branch remains intact with working code.
  • You can create multiple branches
  • Branches are lightweight
  • Copies of your code are not made.
  • E.g. separate branch for each bug fix / feature.
• In git:
  • Run git status to see the base you’re currently working from
  • Create new branch using git branch branchname
  • Switch to the new branch using git checkout branchname
  • At any point, when you want to merge your changes, you can run git merge
    • First you need to be on master git checkout master
    • Then you run git merge feature-branch

Branching Workflows

• Long-Running Branches
  • e.g entirely stable in their master branch
• Topic branches
  • Short-lived branches for particular feature / work
  • There are usually multiple topic branches
• Progressive-stability branching
  • Long-running stable master
  • Another parallel branch named develop or next to test stability
  • It isn’t necessarily always stable, but whenever it gets to a stable state, it can be merged into master
  • Used to pull in topic branches & test so they don’t introduce bugs.
  • 

Centralized Workflow

• There’s only one branch master and everyone commits to master
• Good for teams transitioning from SVN.
• See also trunk-based development

Feature Branch Workflow

• All feature development should take place in a dedicated branch instead of the master branch.
• Logical extension of Centralized Workflow.
• Cons:
  • Easy for multiple developers to work on a particular feature without disturbing the main codebase.
  • master branch should never contain broken code, which is a huge advantage for continuous integration environments.
  • Enables PR’s

Gitflow Workflow

• Strict branching model designed around the project release
• Based on Feature Branch Workflow
• Development:
  • Feature branches are branched off of the develop branch
  • Finished features and fixes are merged back into the develop branch
• Releasing:
  • When it is time to make a release, a release branch is created off of develop.
  • When the release is finished, the release branch is merged into master and into develop too
• 🤗 See Gitflow animation
• 🤗 The Gitflow Workflow was first published in a highly regarded 2010 blog post from Vincent Driessen at nvie

Release-flow

• Based on feature branch workflow
• Enforced in Microsoft
• Development:
  1. Dev creates a new branch off of our main integration
     • 💡 Use feature flags to have short-lived branches
  2. Devs push their local branch to a branch on the server, and open a pull request
  3. When tests are passed, changes are merged into master
• Releases:
  • Releases always result in a tag of the repository
  • A release tag should use a three segment number as defined in Semantic Versioning 2.0.0: MAJOR.MINOR.PATCH
  • If a release branch is necessary release/1.1.x is created.

Forking Workflow

• Each contributor two Git repositories
  • a private local one and a public server-side one.
• E.g. GitHub

Cloning

• Once the code is in a shared repository, a developer can clone the repository
• They can then create a branch out of the current master branch
• They then make changes on their branch

Forking

• Copy of the entire repository
• Commits do not go against the original repository
• Use-cases:
  • Main repository might have issues, so clean new repository is forked for making changes
  • Building application for multiple clients and each client has client-specific features

Pull requests

• A dev has cloned a repo > created a new branch > made changes > commited to branch > pushed branch to remote repo > wants to merge the branch into the branch.
• Developer initiates a pull-requests
  • If there are conflicts between main & uploaded branch
  • They need to be resolved
  • Approval needs to be put into place for the pull request

This site is open source. Improve this page.