You can git
- 1. You can git All you need to know about git, GitHub, VSTS, git GUI, etc… Yu Guan | Microsoft MVP
- 2. AGENDA history of version(or source) control what is git git repo providers start with GUI local vs remote git workflow some best practices
- 3. History of version(or source) control In first generation tools, concurrent development was handled solely with locks. Only one person could be working on a file at a time. The second generation tools are a fair bit more permissive about simultaneous modifications, with one notable restriction. Users must merge the current revisions into their work before they are allowed to commit. The third generation tools allow merge and commit to be separated.
- 4. History of version(or source) control Generation Networking Operations Concurrency Examples First None One file at a time Locks RCS, SCCS Second Centralized Multi-file Merge before commit CVS, SourceSafe, Subversion, Team Foundation Server Third Distributed Changesets Commit before merge Bazaar, Git, Mercurial
- 5. what is git created by Linus Torvalds in 2005 distributed version control systems on every computer is a full-fledged repository with complete history and full version tracking abilities
- 6. git repo providers git != GitHub Provider Framework is open-source? Support for other SCM Open-source repositories Space (GB) Free private repositories GitHub No SVN Yes Unlimited No GitLab.com Yes No Yes Unlimited Unlimited projects, unlimited collaborators bitbucket.org No Mercurial Yes Unlimited Unlimited projects, 5 collaborators Codebase No Mercurial/SV N Public access available 0.05 1 project (unlimited repos), 2 collaborators SourceForge.net Yes Hg, SVN Yes Unlimited No Visual Studio Team Services No TFVC No Unlimited Unlimited, 5 users
- 7. start with GUI Git Extensions GitHub Desktop Visual Studio 2015/2017
- 10. local vs remote create and work with local repo you don’t need to install any source control server side software create and use remote repo GitHub VSTS
- 11. git workflow 1. Create a branch for the changes you plan to make and give it a name, such as fix-bug-3214 or cool-feature-x. 2. Commit changes to your branch. People often have multiple commits for a bug fix or feature. 3. Push your branch to the remote repository. 4. Create a pull request so other people can review your changes. To incorporate feedback, you might need to make more commits and push more changes. 5. Complete your pull request and resolve any merge conflicts from changes other people made after you created your branch.
- 12. git workflow
- 13. Some best practices Branch naming convention feature-{alias/dev/qa}-{main}-{detail} update-{alias/dev/qa}-{main}-{detail} bugfix-{alias/dev/qa}-{main}-{detail} hotfix-{alias/dev/qa}-{main}-{detail} lab-{alias/dev/qa}-{main}-{detail} wip-{alias/dev/qa}-{main}-{detail} Pull Request / Code review
- 14. THANK YOU! Q&A