Techoalien git
Download as PPTX, PDF2 likes5,193 views
The document provides an overview of the version control system using Git, emphasizing its importance for managing files and changes in collaborative software projects. It outlines the basic setup, commands for tracking changes, committing files, branching, merging, and resolving conflicts. Additionally, it discusses advanced Git commands and concepts for effective version control management.
Techoalien git
- 1. Presentedby Aditya Tiwari VERSION CONTROL SYSTEM USING GIT TechoAlien www.techoalien.com
- 2. Learning Version Control •Version Control (aka Revision Control aka Source Control) lets you track your files over time.
- 3. Why do you care? You’ve probably cooked up your own •AdityaResumeOct2013.doc •AdityaResumeMar2014.doc •instacalc-logo3.png •instacalc-logo4.png •logo-old.png
- 4. It’s why we use “Save As”. You want the new file without obliterating the old one. It’s a common problem, and solutions are usually like this: •Make a single backup copy (Document.old.txt). •If we’re clever, we add a version number or date: Document_V1.txt, DocumentMarch2007.txt •We may even use a shared folder so other people can see and edit files without sending them over email. Hopefully they re-label the file after
- 5. So Why Do We Need A Version Control System (CS)? •Our shared folder/naming system is fine for class projects or one-time papers. But software projects? Not a chance. •Do you think the Windows source code sits in a shared folder like “Windows2007-Latest-UPDATED!!”, for anyone to edit? That every programmer just works in a different subfolder? No way.
- 6. •Large, fast-changing projects with many authors need a Version Control System (geekspeak for “file database”) to track changes and avoid general chaos.
- 7. Attributes of Good VCS •Backup and Restore •Synchronization •Short-term undo •Long-term undo •Track Changes •Track Ownership •Sandboxing or Insurance against yourself •Branching and merging
- 8. Basic Setup •Repository (repo) •Server •Client •Working Set/Working Copy •Trunk/Main
- 9. Why Git ? 1.Easy to learn 2.Git is fast 3.Distributed 4.Data Assurance 5.Staging Area 6.Free & open Source (cont….)
- 10. 1.Easy to learn
- 11. 2.Git is Fast
- 12. 3.Distributed GIT supports different types of workflows •Subversion-Style Workflow •Integration Manager Workflow •Dictator and Lieutenants Workflow
- 15. 3.3 Dictator and Lieutenants Workflow
- 17. 5.Staging Area*
- 18. 6. Free and Open Source
- 19. Hand on Git
- 20. Step 1: Create a folder “Octocat”
- 21. Step 2: git init •Initiate git repository •The repository is a hidden directory where Git operates.
- 22. Step 3: git status •The git status command to see what the current state of our project is
- 23. Step 4: Add a file called food.txt add Milk in it
- 24. Step 5:Again git status •staged: Files are ready to be committed. •unstaged: Files with changes that have not been prepared to be committed •untracked: Files aren't tracked by Git yet. This usually indicates a newly created file. •(Difference- Unstaged files are like files that has a node in git, which have changed but not added for commit. untracked are those files which doesn't have a node in git.) •deleted: File has been deleted and is waiting to be removed from Git.
- 25. Step 6 :git add list.txt •Add all : You can also type git add -A . where the dot stands for the current directory, so everything in and beneath it is added. The-A ensures even file deletions are included. •git reset: You can use git reset <filename> to remove a file or files from the staging area. •
- 26. Step: 7 git status •Files are now in staged portion
- 27. Step 8: git commit -m “Octocat likes milk" •Finally committed !!
- 28. Step 9: Some exercise
- 29. Step 10: Now add files furniture.txt and books.txt
- 30. Step 11: git log •git log --summary to see more information for each commit. You can see where new files were added for the first time or where files were deleted. It's a good overview of what's going on in the project.
- 31. Step 12: Create repository on GitHub •Go to github.com
- 32. Step 13: git remote add origin <url> •git remote: Git doesn't care what you name your remotes, but it's typical to name your main one origin. •We are declaring our GitHub repo as origin
- 33. Step 14. git push -u origin master So let's push our local changes to our origin repo (on GitHub). The name of our remote is origin and the default local branch name is master. The -u tells Git to remember the parameters, so that next time we can simply run git push and Git will know what to do. Go ahead and push it!
- 34. Step 15: password caching •If you prefer working with the command line, you can also install a native Git shell, such as msysgit. With msysgit, running the following in the command line will store your credentials •git config --global credential.helper wincred
- 35. Step 16: git pull origin master •Let's pretend some time has passed. We've invited other people to our github project who have pulled your changes, made their own commits, and pushed them. •We can check for changes on our GitHub repository and pull down any new changes
- 36. Step 17: git diff HEAD •The HEAD is a pointer that holds your position within all your different commits. By default HEAD points to your most recent commit, so it can be used as a quick way to reference that commit
- 37. Step 18: Staged Differences •Another great use for diff is looking at changes within files that have already been staged. Remember, staged files are files we have told git that are ready to be committed. •Add home/furniture.txt •Run - git diff –staged •Run- git add home/furniture.txt
- 38. Step 19: git reset home/furnitures •You can unstage files by using the git reset command. Go ahead and remove home/furnitures
- 39. Step 20. Undo •git reset did a great job of unstaging furnitures.txt, but you'll notice that he's still there. He's just not staged anymore. •git checkout --list.txt
- 40. Step 21 : Branching Out Before branching out create version r7
- 41. Step 22 Create new branch Clean_up •git branch clean_up
- 42. Step 23:Switching Branches git branch To see all branches •git checkout clean_up Or •git checkout -b new_branch For creating and checking simultaneously
- 43. Step 24 : Removing All The Things •git rm '*.txt‘ •for all folder remove git rm –r <foldername>
- 44. Step 25: Committing Branch Changes •git commit -m "Remove all the items“ *IMP The '-a' option •If you happen to delete a file without using'git rm' you'll find that you still have to'git rm' the deleted files from the working tree. You can save this step by using the '-a' option on 'git commit', which auto removes deleted files with the commit. •git commit -am "Delete stuff“
- 45. To Do Git add . Git commit –m “r5”
- 46. Step 26 : Switching Back to master •git checkout master •*IMP Pull Requests If you're hosting your repo on GitHub, you can do something called a pull request. A pull request allows the boss of the project to look through your changes and make comments before deciding to merge in the change. It's a really great feature that is used all the time for remote workers and open-source projects.
- 47. Step 27 :Preparing to Merge Run: git merge clean_up
- 48. Step 28 : (IMP) Merge Conflicts •Merge Conflicts can occur when changes are made to a file at the same time. A lot of people get really scared when a conflict happens, but fear not! They aren't that scary, you just need to decide which code to keep. • •<<<<<<< HEAD • XYZ your code •======= • ABC also your code
- 49. How to remove merge conflict
- 50. Step 29 :delete branch •git branch -d clean_up •This will not work for unmerged branch so use git branch -d -f clean_up or git branch -D clean_up
- 51. Step 30 : At Last !! •git push
- 52. Advance Git
- 53. 1. Undoing changes 1.git checkout <commit> 1.git reset <commit> 1.git revert <commit>
- 54. Difference
- 55. Git Checkout •git checkout hotfix •Internally, all the above command does is move HEAD to a different branch and update the working directory to match. Since this has the potential to overwrite local changes, Git forces you to commit or stash any changes in the working directory that will be lost during the checkout operation. Unlike git reset, git checkout doesn’t move any branches around.
- 57. Git Reset •git checkout hotfix •git reset HEAD~2 •
- 58. Git Reset (Cont..) •--soft – The staged snapshot and working directory are not altered in any way. •--mixed – The staged snapshot is updated to match the specified commit, but the working directory is not affected. This is the default option. •--hard – The staged snapshot and the working directory are both updated to match the specified commit.
- 59. Git Revert •Reverting undoes a commit by creating a new commit. This is a safe way to undo changes, as it has no chance of re-writing the commit history. For example, the following command will figure out the changes contained in the 2nd to last commit, create a new commit undoing those changes, and tack the new commit onto the existing project. •git checkout hotfix •git revert HEAD~2
- 60. This can be visualized as the following:
- 61. Using these commands •If a commit has been made somewhere in the project's history, and you later decide that the commit is wrong and should not have been done, then git revert is the tool for the job. It will undo the changes introduced by the bad commit, recording the "undo" in the history. •If you have modified a file in your working tree, but haven't committed the change, then you can use git checkout to checkout a fresh-from- repository copy of the file.
- 62. More… •git commit --amend •git rebase •git reflog •*git fetch The git fetch command imports commits from a remote repository into your local repo. The resulting commits are stored as remote branches instead of the normal local branches that we’ve been working with. This gives you a chance to review changes before integrating them into your