Git usage (Basics and workflow)
Download as PPTX, PDF0 likes211 views
Git is a distributed version control system that allows developers to work collaboratively. It uses a local repository that is regularly synced with a remote repository. The document discusses Git basics like initialization, tracking files, commits, branches and common workflows like Gitflow. Specific commands covered are add, commit, checkout, rebase, stash, cherry-pick and how to undo faulty pushes. Key advantages of Git over SVN are also highlighted.
Git usage (Basics and workflow)
- 1. Git usage (Basics and workflow) - YEASIN ABEDIN SIAM (NAUTISK TEAM) - HASAN IBRAHIM SHUVO (NAUTISK TEAM)
- 2. What is Git? ļµ Version Controlling System ļµ Distributed Mechanism ļµ Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it
- 3. Centralized vs Decentralized VCS ļµ Centralized version control systems are based on the idea that there is a single ācentralā copy of your project somewhere (probably on a server), and programmers will ācommitā their changes to this central copy. ļµ āCommittingā a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed. ļµ Example CVS, Subversion (or SVN) and Perforce
- 5. Git tools ļµ Install Git ļµ Install Git Client (TortoiseGit, SourceTree, Git for VisualStudio) ļµ Some client includes git as well (example Github Desktop, SourceTree)
- 6. Working with Git ļµ To start working with Git, you just need to run the "git init" command. It turns the current directory into the Git working directory and creates the repository in the .git (hidden) directory it creates there. ļµ The āgit addā command adds untracked file in the staging area. ļµ The āgit commitā command commits the changes in the file. ļµ The āgit checkoutā checks out a branch from repository into the working directory
- 7. Git Workflow
- 8. File tracking Git sees every file in your working copy as one of three things: ļ§ tracked - a file which has been previously staged or committed; ļ§ untracked - a file which has not been staged or committed; or ļ§ ignored - a file which Git has been explicitly told to ignore.
- 9. .gitignore file ļµ Dependency caches, such as the contents of /node_modules or /packages ļµ Compiled code, such as .o, .pyc, and .class files ļµ Build output directories, such as /bin, /out, or /target ļµ Files generated at runtime, such as .log, .lock, or .tmp ļµ personal IDE configuration files, such as .idea/workspace.xml ļµ Existing ignore patterns : https://github.com/github/gitignore
- 11. Git vs SVN ļµ Git is distributed system whereas SVN is centralized. ļµ Git is faster than SVN. ļµ Git repositories are much smaller than SVN. ļµ Git are simpler and lees resource heavy than SVNās. ļµ Git tracks content unlike SVNās file tracking ļµ Merging is simpler in Git; because you donāt need to remember the last revision you merged from which is required in SVN. ļµ Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes.
- 12. Git vs Mercurial ļµ Mercurial is much simpler than Git. ļµ Git has better history control than Mercurial. ļµ Branching is more powerful in Git. ļµ Git has staging area, mercurial doesnāt have ļµ Mercurial has better GUI support
- 13. GitFlow
- 14. What is GitFlow? ļ GitFlow is a branching model for Git. ļ Created by Vincent Driessen. ļ Well suited to collaboration and scaling the development team.
- 15. Motivations ļµ Parallel Development ļµ Collaboration ļµ Release staging area ļµ Support for emergency fixes
- 16. Branches ļµ Feature branch ļµ Develop branch ļµ Release branch ļµ Hotfix branch ļµ Master branch
- 17. Feature Branch ļ Feature branches are started off of the develop branch. ļ Finished features and fixes are merged back into the develop branch when theyāre ready for release
- 18. Feature Branch
- 19. Release ļ When it is time to make a release, a release branch is created off of develop branch ļ The code in the release branch is deployed onto a suitable test environment, tested, and any problems are fixed directly in the release branch. This deploy -> test -> fix -> redeploy -> retest cycle continues until youāre happy that the release is good enough to release to customers. ļ When the release is finished, the release branch is merged into master and into develop too, to make sure that any changes made in the release branch arenāt accidentally lost by new development.
- 20. Release
- 21. Master Branch ļ The master branch tracks released code only. ļ The only commits to master are merges from release branches and hotfix branches.
- 22. Hotfix Branch Hotfix branches are used to create emergency fixes.
- 23. Hotfix Branch
- 25. Git Stash ļµ We have changes which are temporary ļµ But, we donāt want to commit this ļµ Neither, we want to loose it ļµ Stash saves state of current working changes ļµ But Git does not track them for commit ļµ We can compare working copy with stash ļµ Stash can be merged to master
- 26. Git Rebase
- 27. Git Rebaseā¦
- 28. Git Rebaseā¦
- 29. Git Rebaseā¦
- 30. Git Rebaseā¦
- 31. Git Rebaseā¦
- 32. Use case : Remove faulty push ļµ Some faulty commits has been pushed to remote ļµ We want to revert back ļµ How can we do this?
- 33. Solution ļµ Reset master to a commit which is Stable (Hard Reset - local) ļµ Now, you are in master and do a FORCE PUSH. ļµ git push -f origin master:master # force push
- 34. Cherry Pick ļµ You're working in a feature branch ļµ Isn't quite ready for a full merge. ļµ But you do have a few commits in there that you want to push to master ļµ We can do this by Cherry Pick ļµ Allow us to merge specific number of commits
- 35. Refrences ļµ https://git-scm.com/book/en/v2/Getting-Started-Git-Basics ļµ https://www.ibm.com/developerworks/library/d-learn-workings- git/index.html ļµ https://www.atlassian.com/git/tutorials/gitignore ļµ https://www.atlassian.com/git/tutorials/gitignore#git-ignore-patterns ļµ https://datasift.github.io/gitflow/IntroducingGitFlow.html ļµ http://nvie.com/posts/a-successful-git-branching-model/