1. GIT An introduction to GIT Source Control

2. What is GIT (1 of 2) ▪ “Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.” ▪ Multi Platform (Windows, MAC, Linux, Android!) [SGit]SGit ▪ Open Source [GitHub Repository]GitHub Repository ▪ Distributed Source Control [Centralised / Distributed]CentralisedDistributed – Centralized VCS systems are designed with the intent that there is One True Source that is Blessed, and therefore good. All developers work (checkout) from that source, and then add (commit) their changes, which then become similarly Blessed. – In a distributed model, every developer has their own repo. Sue’s changes live in her local repo, which she can share with Joe or Eve. Distributed version control focuses on sharing changes; every change has a unique id. – Use Case: In a distributed model, two Developers can work on the same story sharing changes without affecting the main branches – Aiding TDD?.

3. What is GIT (2 of 2) ▪ Developed by Linus Torvalds (Founder of Linux) loosely based on Bit Keeper SCM [Interview]Interview ▪ Widely adopted in the Industry. – Including favour with Microsoft [Support Announcement]Support Announcement – Integrates with Visual Studio and Visual Studio Online (VSO)

4. Key Differences between TFS and GIT ▪ TFS is Centralised. ▪ GIT does not need separate local copies for each environment (IE: DEV/UAT/Release 1.31) ▪ Each branch in TFS is expensive (Each branch is a full copy of the code). In GIT branches merely reference a snapshot and contain the changes. ▪ No need to maintain release branches in GIT (Labelling in TC?) ▪ Source Control Explorer is not available for GIT (Visual Studio) ▪ GIT is at its best when using “Feature Branches” – One Branch per User Story – Each Story/Branch is progressed independently and in isolation to unrelated changes. – Individual stories can be deployed to Live.

5. Some Other Advantages of GIT ▪ Disposable Experimentation [Source]Source – “Disposable Experimentation. Create a branch to experiment in, realize it's not going to work, and just delete it - abandoning the work—with nobody else ever seeing it (even if you've pushed other branches in the meantime).” ▪ Offline Access to the REPO [Source]Source – “When I'm working at home (or in an airplane or train), I can see the full history of the project, every single check-in, without starting up my VPN connection to work and can work like I were at work: checking, checkout, branch, anything.” ▪ GIT is fast – “Nearly all operations are performed locally, giving it a huge speed advantage on centralized systems that constantly have to communicate with a server somewhere”. [Why you should switch to GIT] [Quote]Why you should switch to GITQuote

6. Disadvantages of Adopting GIT ▪ Initial Learning Curve ▪ Transition from different technology (IE: TFS) affecting things such as Build Processes

7. GIT Branches (1 of 2) ▪ “A branch in Git is simply a lightweight movable pointer to a commit” ▪ “As you start making commits, you’re branch points to the last commit you made. Every time you commit, it moves forward automatically.”

8. GIT Branches (2 of 2)

9. Tools for Interacting with GIT ▪ Visual Studio 2013. ▪ Visual Studio 2015 (Improved over VS 2013). ▪ Command Line Interface – IE: PowerShell. ▪ GitHub / SmartGit and many more. ▪ Combination of multiple tools at once. ▪ I recommend a combination of Visual Studio and Command Line

10. The Three States [Source]Source ▪ Git has three main states that your files can reside in; committed, modified and staged. – Committed means that the data is safely stored in your branch. – Modified means that you have changed the file but have not committed it to your branch yet – Staged means that you have marked a modified file in its current version to go into your next commit. ▪ You can only work in one branch at a time. COMMIT or STASH changes if you need to change Branch ▪ “The major difference between Git and any other is the way Git thinks about its data. Conceptually, most systems store information as a list of file-based changes. These systems think of the information they keep as a set of files and the changes made to each file over time.” ▪ “Git doesn’t think of or store its data this way.Git thinks of its data more like a set of snapshots of a file system. Every time you commit, or save the state of your project in Git, it takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored.”

11. Key Terminology ▪ REPO: The Repository / Project which contains multiple branches (IE: JLR DSE). ▪ CLONE: Downloads a REPO to your local machine. ▪ INIT: Starts a new REPO on your local machine. ▪ FETCH: Looks for changes in the remote REPO. (Get History) ▪ PULL: Downloads the latest commits from the remote REPO to your current Branch (Get Latest) ▪ COMMIT: A check-in of changes to files (Performed locally) ▪ PUSH: Uploads the commits you have made to the current Branch up to the remote REPO ▪ CHECKOUT: Switches to a different branch on your local machine. ▪ Prefix any command line executions with GIT (IE: GIT PULL OR GIT COMMIT)

12. Getting Started with GIT ▪ Install GIT (If you don’t have it already) [Link] [Link] ▪ CLONE a REPO – Cloning downloads a REPO and attaches the REMOTE ORIGIN ▪ PULL Branches – Download the key branches (IE, DEV, UAT, PDT, MASTER) – GIT CHECKOUT ORIGIN DEV – Download the remote Branch called DEV to your local REPO and make it the Current Branch.

13. Working on your Story ▪ Get Latest – GIT CHECKOUT DEV – GIT PULL ▪ Create a Feature Branch – Feature Branch Naming Convention: “12345\StoryDescription” (Future Proof Description) – GIT BRANCH 12345\StoryDescription – GIT CHECKOUT 12345\StoryDescription ▪ Modify Files – Alter your files…. – GIT COMMIT –m “This is what my commit adds” – GIT PUSH

14. Merging your Story into DEV ▪ Dev Test on your Local Machine ▪ Create a Pull Request (Ready for Peer Review)

15. Code Review and Peer Test ▪ Other Developers Access Pull Request.

16. Quick Demo (If there is time)