Git walkthrough
Download as PPTX, PDF•0 likes•56 views
Git is a version control system created by Linus Torvalds in 2005 for tracking changes in source code over time. It allows for non-linear development through features like branching and distributed collaboration. The document provides an overview of common Git concepts and commands including initializing and cloning repositories, tracking file changes, committing snapshots of changes to the local repository, and interacting with remote repositories by pushing and pulling changes. Best practices for Git include not pushing directly to master, defining code owners, avoiding secrets and dependencies in commits, and maintaining a meaningful .gitignore file.
Git walkthrough
- 1. Click to edit Master title style 1 GIT B a s i c s , L i f e c y c l e , B e s t p r a c t i c e s
- 2. Click to edit Master title style 2 2 • Created by Linus Torvalds, creator of Linux, in 2005 • Came out of Linux development community • Designed to do version control on Linux kernel • Goals of Git: • Speed • Support for non-linear development • (thousands of parallel branches) • Fully distributed • Able to handle large projects efficiently • (A "git" is a cranky old man. Linus meant himself.) About
- 3. Click to edit Master title style 3 3 • Git website: http://git-scm.com/ • Free on-line book: http://git-scm.com/book • Reference page for Git: http://gitref.org/index.html • Git tutorial: http://schacon.github.com/git/gittutorial.html • Git for Computer Scientists: • http://eagain.net/articles/git-for-computer-scientists/ • At command line: (where verb = config, add, commit, etc.) • git help verb Learning GIT
- 4. Click to edit Master title style 4 Basics D a y t o d a y a c t i v i t i e s w i t h G I T 4
- 5. Click to edit Master title style 5 5 • In Subversion, CVS, Perforce, etc. A central server repository (repo) holds the "official copy" of the code • the server maintains the sole version history of the repo • You make "checkouts" of it to your local copy • you make local modifications • your changes are not versioned • When you're done, you "check in" back to the server • your check in increments the repo's version Centralized VCS
- 6. Click to edit Master title style 6 6 • In git, mercurial, etc., you don't "checkout“ from a central repo • you "clone" it and "pull" changes from it • Your local repo is a complete copy of everything on the remote server • yours is "just as good" as theirs • Many operations are local: • check in/out from local repo • commit changes to local repo • local repo keeps version history • When you're ready, you can "push" changes back to server Distributed VCS (Git)
- 7. Click to edit Master title style 7 7 • Centralized VCS like Subversion track version data on each individual file. • Git keeps "snapshots" of the entire state of the project. • Each checkin version of the overall code has a copy of each file in it. • Some files change on a given checkin, some do not. • More redundancy, but faster. Git Snapshots Git Subversion
- 8. Click to edit Master title style 8 8 • In your local copy on git, files can be: • In your local repo • (committed) • Checked out and modified, but not yet committed • (working copy) • Or, in-between, in a "staging" area • Staged files are ready to be committed. • A commit saves a snapshot of all staged state. Three state
- 9. Click to edit Master title style 9 9 • Modify files in your working directory. • Stage files, adding snapshots of them to your staging area. • Commit, which takes the files in the staging area and stores that snapshot permanently to your Git directory. Basic Git workflow
- 10. Click to edit Master title style 1010 In Subversion each modification to the central repo increments the version # of the overall repo. – In Git, each user has their own copy of the repo, and commits changes to their local copy of the repo before pushing to the central server. – So Git generates a unique SHA-1 hash (40 character string of hex digits) for every commit. – Refers to commits by this ID rather than a version number. – Often we only see the first 7 characters: • 1677b2d Edited first line of readme • 258efa7 Added line to readme • 0e52da7 Initial commit Commit checksums
- 11. Click to edit Master title style 1111 • Set the name and email for Git to use when you commit: – git config --global user.name "Bugs Bunny" – git config --global user.email [email protected] – You can call git config –list to verify these are set. • Set the editor that is used for writing commit messages: – git config --global core.editor nano - git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar - nosession -noPlugin" • (it is vim by default) Initial configuration
- 12. Click to edit Master title style 1212 Two common scenarios: (only do one of these) • To create a new local Git repo in your current directory: – git init • This will create a .git directory in your current directory. • Then you can commit files in that directory into the repo. – git add filename – git commit –m "commit message" • To clone a remote repo to your current directory: – git clone url localDirectoryName • This will create the given local directory, containing a working copy of the files from the repo, and a .git directory (used to hold the staging area and your actual local repo) Creating Git repo
- 13. Click to edit Master title style 1313 Git commands
- 14. Click to edit Master title style 1414 Add/Commit • The first time we ask a file to be tracked, and every time before we commit a file, we must add it to the staging area: – git add Hello.java Goodbye.java • Takes a snapshot of these files, adds them to the staging area. • In older VCS, "add" means "start tracking this file." In Git, "add“ means "add to staging area" so it will be part of the next commit. • To move staged changes into the repo, we commit: – git commit –m "Fixing bug #22" • To undo changes on a file before you have committed it: – git reset HEAD -- filename (unstages the file) – git checkout -- filename (undoes your changes) – All these commands are acting on your local version of repo.
- 15. Click to edit Master title style 1515 Viewing/Undoing changes • To view status of files in working directory and staging area: – git status or git status –s (short version) • To see what is modified but unstaged: – git diff • To see a list of staged changes: – git diff --cached • To see a log of all changes in your local repo: – git log or git log --oneline (shorter version) 1677b2d Edited first line of readme 258efa7 Added line to readme 0e52da7 Initial commit • git log -5 (to show only the 5 most recent updates), etc. • Unstage a staged file – $ git reset HEAD CONTRIBUTING.md (short version) • Unmodifying a Modified File – git checkout -- modifiedfile
- 16. Click to edit Master title style 1616 Sample workflow $ vim rea.txt $ git status no changes added to commit (use "git add" and/or "git commit -a") $ git status -s M rea.txt $ git diff diff --git a/rea.txt b/rea.txt $ git add rea.txt $ git status # modified: rea.txt $ git diff --cached diff --git a/rea.txt b/rea.txt $ git commit -m "Created new text file“ $ git add forgotten_file $ git commit --amend
- 17. Click to edit Master title style 17 17s dfd xdx dfsz Managing change • Branching • Merging • Rebasing • Cherry-picking • Stashing
- 18. Click to edit Master title style 1818 Branching/Merging Git uses branching heavily to switch between multiple tasks. • To create a new local branch: • git branch name • To list all local branches: (* = current branch) • git branch • To switch to a given local branch: • git checkout branchname • To merge changes from a branch into the local master: • git checkout master • git merge branchname
- 19. Click to edit Master title style 1919 Branching git branch testing
- 20. Click to edit Master title style 20 20 Merging In Git, the merging is a procedure to connect the forked history. It joins two or more development history together. The git merge command facilitates you to take the data created by git branch and integrate them into a single branch. Git merge will associate a series of commits into one unified history. Generally, git merge is used to combine two branches. git merge <commit> git mergetool #To resolve conflict
- 21. Click to edit Master title style 2121 Merge conflicts • The conflicting file will contain <<< and >>> sections to indicate where Git was unable to resolve a conflict: • Find all such sections, and edit them to the proper state (whichever of the two versions is newer/better/ more correct).
- 22. Click to edit Master title style 22 22 Rebasing • Rebasing is a process to reapply commits on top of another base trip. It is used to apply a sequence of commits from distinct branches into a final commit. It is an alternative of git merge command. It is a linear process of merging. • git rebase <branch name>
- 23. Click to edit Master title style 2323 Cherry-picking • Cherry-picking in Git stands for applying some commit from one branch into another branch. In case you made a mistake and committed a change into the wrong branch, but do not want to merge the whole branch. You can revert the commit and apply it on another branch. • git cherry-pick <commit id> • git cherry-pick master • git cherry-pick ..master • git cherry-pick ^HEAD master • git cherry-pick maint next ^master • git cherry-pick maint master..next
- 24. Click to edit Master title style 24 24 Stashing • Stashing takes the dirty state of your working directory — that is, your modified tracked files and staged changes — and saves it on a stack of unfinished changes that you can reapply at any time (even on a different branch). git stash Saved working directory and index state "WIP on master: 049d078 Create index file" HEAD is now at 049d078 Create index file (To restore them type "git stash apply") git stash list stash@{0}: WIP on master: 049d078 Create index file stash@{1}: WIP on master: c264051 Revert "Add file_size" stash@{2}: WIP on master: 21d80a5 Add number to log git stash apply #if you want to apply last stash git stash apply stash@{2} #if you want to apply specific stash
- 25. Click to edit Master title style 25 25 Interaction with remote repo • Push your local changes to the remote repo. • Pull from remote repo to get most recent changes. – (fix conflicts if necessary, add/commit them to your local repo) • To fetch the most recent updates from the remote repo into your local repo, and put them into your working directory: – git pull origin master • To put your changes from your local repo in the remote repo: – git push origin master
- 26. Click to edit Master title style 26 26 Github • GitHub.com is a site for online storage of Git repositories. – You can create a remote repo there and push code to it. – Many open source projects use it, such as the Linux kernel. – You can get free space for open source projects, or you can pay for private projects. • Free private repos for educational use: github.com/edu • Question: Do I always have to use GitHub to use Git? – Answer: No! You can use Git locally for your own purposes. – Or you or someone else could set up a server to share files. – Or you could share a repo with users on the same file system, as long everyone has the needed file permissions).
- 27. Click to edit Master title style 2727 Github repo permission level • Read: Recommended for non-code contributors who want to view or discuss your project • Triage: Recommended for contributors who need to proactively manage issues and pull requests without write access • Write: Recommended for contributors who actively push to your project • Maintain: Recommended for project managers who need to manage the repository without access to sensitive or destructive actions • Admin: Recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository
- 28. Click to edit Master title style 28 28 Typical flow
- 29. Click to edit Master title style 29 Terminologies Te r m s u s e d w i t h i n G I T e c o s y s t e m 29
- 30. Click to edit Master title style 3030 Terminologies
- 31. Click to edit Master title style 3131 Terminologies
- 32. Click to edit Master title style 32 Best practices E s t a b l i s h e d c o n v e n t i o n s 32
- 33. Click to edit Master title style 3333 1. Don’t git push straight to master (branch protection) 2. Don’t commit code as an unrecognized author 3. Define code owners for faster code reviews 4. Don’t leak secrets into source control 5. Don’t commit dependencies into source control 6. Don’t commit local config files into source control 7. Create a meaningful git ignore file 8. Archive dead repositories 9. Lock package version 10.Leverage task list Best practices
- 34. Click to edit Master title style 34 Thank You