Git is...

• A version control system
• Decentralized / Distributed
  • There is no "central" repository
  • Each repo is a fully functional, full copy of all changes*
  • There are, however, remote repos
  • Yes, you *can* use remote repos as the 1 central repo
• Able to work completely offline
• Helpful to think in terms of graph theory (DAG)

Git is not...

• SVN or TFVC
  • Git offers many more operations than SVN of TFVC does
  • Some of the terminology and concepts aren't exactly analogous

!=

||

More differences...

• A git repo is cloned to your local machine
  • You check out a SVN/TFS location to your local machine
  • In Git, you check out certain commits or branches
    • This is a branch switch in SVN/TFS
• A SVN/TFS commit increments the revision and the changes are automatically in the central repo
  • A commit in Git creates a hash,  and not necessarily pushed to a remote
• Git: local branches can be created without a corresponding remote branch
  • In fact, this is encouraged!
• SVN commits track changes
  • Each git commit has a snapshot of all files

Branching

Branching

• Branching should be part of your everyday workflow
• When in doubt, branch
• Commit and push without fear into branches
• Git allows for different development "contexts" (or topics, or streams)
  • new features
  • bug fixes
  • experimental development
• Consider remote branches when
  • multiple devs are working on the same feature, etc.
  • managing releases (dev, test, prod)

Merging

• Git merges an entire branch into another
• Git figures out which commits needs to be "copied" into a branch - easy merge
• Many times it will need to do a 3-way merge to consolidate multiple changes (a merge commit). Usually happens when commits have been made to both branches after the branch had been created
• In fact, a pull is just a fetch and then a merge

Merging

Plain (easy, fast forward)

Merging

Merge commit / 3-way merge

The team workflow - a possible solution

Scenario: Feature101 needs to built. 2 devs are assigned.

1. Dev1 and Dev2 clone the repo, if they haven't already
2. Feature101 branch created on remote repo
3. Dev1 and Dev2 create local feature branch and checkout Feature101 branch, or push to a newly created feature branch if it doesn't already exist
4. Both devs work on Feature 101, committing and pushing changes
5. Once done, they send pull request to project manager/tech lead/release management
6. Changes are reviewed
   1. Can be accepted
   2. or more changes needed
7. Pull request accepted. Feature101 branch merged into master (or production or whatever) branch.

The team workflow continued

The team workflow continued

More thoughts

• Should be working with a local development branch by default
• Minimizes code conflicts or changes being inadvertently merged/overwritten when pulling commits
• Allows you to stick to the "commit early and often" practice without fear
• If more than one dev are working in the same development/feature branch, you can even branch from that
• Informative commit messages are important for discussions around pull requests

The team workflow continued

With VSO

• Devs can make comments on pull requests, commits, or even lines of code
  • A tool for code reviews and discussions
• Security can be at the branch level
  • We can manage our own release process (for example: only build admins have access to merge code into Prod branch)
• We can use VSO to track development tasks
  • Commits can be associated with work items, like you can with TFVC