Skip to content

Latest commit

 

History

History
125 lines (102 loc) · 5.6 KB

9.1. Git.md

File metadata and controls

125 lines (102 loc) · 5.6 KB
Raw

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 <branch-name>
    • Switch to the new branch using git checkout <branch-name>
    • 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.
    • A "silo" view of progressive-stability branching

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