Git for developers from TFS world

This is for developers from TFS world
In three levels, you will be comfortable on using Git from command line for your Visual Studio projects

Transcript

1. Sheik Uduman Ali M for .NET and Visual Studio folks
2. : A request : Use Git Bash command line tool to interact with git
3. Level 1 git object model commit, pull, push
4. Git is not like TFS, in many ways _ but this one is very basic git local (.git folder) git remote working folder tfs working folder
5. your source code folder always interacts with git local git init git local is the way to interact with remote repo myproject (on an empty folder) you can create a git local repo from scratch, or clone it from remote git clone https://blahblah.git myproject (blahblah remote) myproject (on an empty folder)
6. it is strongly recommended to keep your code files only in repository your VS projects always have so many non-code files • package files • operational folders like bin, obj • executable and DLLs • you should exclude them by placing .gitignore file on the logically root folder • you can have multiple .gitignore with different exclusion lists on different folders • always .gitignore at root take precedence • of course, you should specify exclusion file patterns on .gitignore • ready to consume .gitignore files for .NET projects available on web
7. Exercise 1. Create a repository in bitbucket (one of the SaaS git) 2. Choose a folder in you local machine 3. Clone the remote repository 4. Check the presence of .git folder 5. Place the .gitignore file at the root 6. Create a VS project in the folder
8. In VS team explorer, check the presence of the repository
9. You should add the folders recursively into git local git add . then commit the changes to the git local git commit –m “project created”
10. git local changes in current folder stage git add git add means get ready for a commit. stage is also called as cache or index
11. git local stage commit object (d23683) git commit commits creates a commit object that contains your changes
12. In git (under .git folder) every single file is stored as blob file name is a SHA-1 checksum simply hash hello.cs 83/baae61804e65cc73a7201a7252750c76066a30 .git / objects/ git has an object model
13. another object type is tree for storing files together (folders, subfolders, files) this also identified by hash blob WishApp.sln WishApp.Api blob WishApi.cs
14. another object type is commit this will simply create a commit for given tree this also identified by hash d23683eb0da78481f6078ee3e397a72ec21fd6fe blob WishApp.sln WishApp.Api blob WishApi.cs commit
15. to know what are the commits you made on git local git log
16. Let us push this to remote repository git push it prompts to enter your remote repository credential
17. So, the process is 1. Add your current changes into stage (add does not mean adding your new files) 2. Commit 3. fetch from remote 4. merge with local (you may need to resolve if any blob or tree conflicts) 5. push the commit to the remote git pull is a composition of step 3 and 4 hence, no more check-out and check-in as in TFS. Its pull and push in git world
18. Level 2 branches
19. branch is highly encouraged practice unlike other source control systems particularly TFS master HEAD : creating a branch in git is just creating a file recent commit d23683eb0d master is the first and default branch
20. to understand branches and HEAD, let us first understand the git object model blob WishApp.sln WishApp.Api blob WishApi.cs commit
21. blob WishApp.sln WishApp.Api blob WishApi.cs commit (d23683eb) master HEAD immutable object references
22. references (pointers) can change their pointers at any point in time, but objects are constant. branches and remotes are references type branch is nothing but a pointer to a recent commit by its hash using the HEAD pointer. Exercise Lets modify a CS file in the VS project and commit (32c3e82c)
23. HEAD d23683eb0d master 32c3e82c master branch points to new commit object (32c3e82c) git branch
24. hence, you can create as much branch you require in git. It is cheap and powerful. Exercise create a branch named dev git checkout -b dev git checkout is actually switching to another branch -b option instructs to create that branch, this actually calls git branch dev
25. switching to another branches is make your working directory look like the tree that branch points to the recent commit and move HEAD file to that branch ; (confused?) in a simpler term, consider your working directory as virtual, based on the branch the directory structure will be reconstituted you can assume reconstitution as simply extract the top tree object of the commit into the working directory. the commit is referred by the current branch.
26. HEAD d23683eb0d master 32c3e82c dev next commit will happen on dev branch switching between branches
27. Exercise 1. do some changes in any files, commit on dev branch 2. switch between dev and master. check the reactions in Visual Studio HEAD d23683eb0d master 32c3e82c dev 16f7afdc3
28. if you want to create a branch from different branch that is not your current working directory, then git checkout -b feature1 dev this instructs git local that create feature1 branch from dev branch currently referred commit
29. merging one branch commit (dev) to another branch (master) git checkout master (if you are in dev branch) git merge dev (merge changes from dev) git push (to push it to origin/master)
30. Level 3 remotes general best practices
31. Remotes they are basically pointers to branches in other peoples copies of the same repository on cloning, you actually get from a remote repository it is added as origin by default
32. How to push the new commit on new branch to remote if you use just git push, git will respond The current branch dev has no upstream branch so, use git push --set-upstream origin dev
33. the recommended practice for git branches master dev featureA mC1 dC1 bC1 • in the above, dashed lines between commits show the child to parent history • lines from branch to commit show current commit the branch refers • dashed line between commits in different branches represent the birth of that branch aC1 featureB aC3
34. the recommended practices for git branches • define dev, qa and feature specific branches • dev – recent stable development changes from various feature branches • qa – more stable commit from dev for QA team to use • feature specific – feature wise branch that is derived from dev • master – always has production ready commit from qa master dev featureA mC1 dC1 bC1 aC1 featureB aC3
35. the process • feature specific team to use featureA local and origin/featureA branches within your feature team • get latest commit from dev whenever a new commit on dev and merge it with your branches • once you complete your development, merge it with dev and push it to origin/dev master dev featureA mC1 dC1 bC1 aC1 featureB aC3
36. access control • restrict all developers to push anything to origin/qa • a person from qa or dev should own to push changes to origin/qa • pay attention on push your commits to dev (recommendation: enforce PULL REQUEST) • qa certified commit only pushed to master master dev featureA mC1 dC1 bC1 aC1 featureB aC3
37. What we learned? • git object model • add, commit, pull and push mechanism • branches • best practices • importantly how git is different from TFS