![Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk
Starting your repo
● git init - create a git repository
● git add <file> [<file2>...] - add files to the index for commit
● git commit - creates a commit with all the files in the staging area. Prompts
for a command message
○ Pro tip: git commit -m “Short concise message” to make the message faster
● git log - shows all the commits in your current branch
○ Pro tip: git log -p - to show the commit including code changes (diff)
○ Pro tip: git log --oneline - to show the logs in short mode
● git show <revision> - show the diff of a specific commit](https://image.slidesharecdn.com/gitbasics-240425134541-0bff7e35/85/Git-Basics-walkthough-to-all-basic-concept-and-commands-of-git-14-320.jpg)
![Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk
Remotes
● Remotes are repositories that are backed up in some server (e.g. GitHub )
● Use for collaboration and backup
● git clone <URL> - retrieves a repository into a directory
○ ssh://[user@]host.xz[:port]/path/to/repo.git/
○ git://host.xz[:port]/path/to/repo.git/
○ http[s]://host.xz[:port]/path/to/repo.git/
git is the
baaeest](https://image.slidesharecdn.com/gitbasics-240425134541-0bff7e35/85/Git-Basics-walkthough-to-all-basic-concept-and-commands-of-git-41-320.jpg)
![Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk
Remotes
● git fetch [<remote>] - retrieves all references, doesn’t modify working
copy
● git pull [<remote> [<branch>]] - retrieves all changes from remote
into your local branch (default: origin, master)
● git push [<remote> [<branch>]] - pushes your local changes to
branch in remote
Attention!! Pull can create conflicts](https://image.slidesharecdn.com/gitbasics-240425134541-0bff7e35/85/Git-Basics-walkthough-to-all-basic-concept-and-commands-of-git-43-320.jpg)
Git Basics walkthough to all basic concept and commands of git
- 1. secret sauce Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk
- 2. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk What is git? ● Source code management tool my_code.py my_code_NEW.py my_code_NEW2.py my_code_final.py my_code_DEFINITELY_FINAL.py
- 3. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk What is git? Distributed instead of centralised: ● Each user has a full copy of the repo
- 4. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk What is git? ● It’s not GitHub! ● GitHub is an internet hosting provider that hosts your code and you can manage it using git
- 5. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk What is git useful for? ● Reproducibility ● Collaboration ● Debugging
- 6. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk GUIs This talk is about the commands and concepts. Everything is done on the Linux terminal, but there are lots of GUIs that are helpful to manage your repository. Some GUIs are integrated into your IDE (like VSCode). For more: https://git-scm.com/downloads/guis
- 7. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Terminology ● Repository (repo): contains the project’s code and changes ● Working copy: your own copy of the repository ● Commit: a git object that represents changes to the code ● Revision: a reference to a git object. In practice, is a version of your codebase ● Working tree or working area: where you work and make changes ● Index or staging area: changes that we want to commit
- 8. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Development history ● Tracks changes to our source code ○ Like a timeline or tree of changes ● Good and clean history is important: ○ Easier code reviewing ○ More difficult to introduce problems ○ Make debugging much easier ○ Code quality!
- 9. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Keeping track of changes with commits ● Every change is a commit with: ○ A unique identifier ○ A date ○ An author ○ A clear and concise message ○ A set of changes to the code (diff) ● Good messages for good history: ○ Short description in imperative ○ Blank line ○ Long description ● Commit ID: SHA1 ○ Hash: means it’s unique! ○ It encodes history commit 2bedc34e012778ca0abb70c14e9e40d13a81f53e Author: Violeta Menendez Gonzalez <v.menendezgonzalez@surrey.ac.uk> Date: Wed May 25 15:54:31 2022 +0100 Check if cuda available before using diff --git a/train.py b/train.py index bc31650..10ebd4f 100644 --- a/train.py +++ b/train.py @@ -572,4 +572,5 @@ if __name__ == '__main__': try: main() finally: - print(torch.cuda.memory_summary(abbreviated=True)) + if torch.cuda.is_available(): + print(torch.cuda.memory_summary(abbreviated=True))
- 10. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk History is editable ● Vital for good history ● Local history is editable: ○ Don’t modify history that has been pushed to the shared repo ● History needs to be clean: ○ Linear: commits don’t depend on later commits, we don’t want commits to break the system ○ Atomic: commits need to be concise, fixing only one bug or implementing only one feature. Pro tip: if the commit message contains the word ‘and’ maybe think of breaking it down!
- 11. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Workflow ● Work in branches (feature branches) ● Main branch (master) for tested and clean changes
- 12. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Workflow ● Commits have an order, you may need to re-order to have a sensible history ● HEAD of a branch is the last commit
- 13. Basic commands
- 14. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Starting your repo ● git init - create a git repository ● git add <file> [<file2>...] - add files to the index for commit ● git commit - creates a commit with all the files in the staging area. Prompts for a command message ○ Pro tip: git commit -m “Short concise message” to make the message faster ● git log - shows all the commits in your current branch ○ Pro tip: git log -p - to show the commit including code changes (diff) ○ Pro tip: git log --oneline - to show the logs in short mode ● git show <revision> - show the diff of a specific commit
- 15. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Working area ● git status - shows the status of your working area, files added, changed, removed, conflicts, files staged… ● git diff - shows all code changes in your working area. You may have several commits worth of changes ● git add -p - add individual changes to the index ● git diff --cached - show all changes that have been staged. If there’s something you don’t like you can make changes ● git reset HEAD <file> - remove changes in a file from the index
- 16. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Workflow You have several commits worth of code changes in your working tree ● git diff - see changes ● git add -p - add individual changes ● git diff --cached - double check changes you have staged for commit ● git reset HEAD <file> - remove any changes you don’t like from the index ● git add -p - add any changes you missed ● git commit - commit changes with a good commit message ● git log -p - double check your commit looks OK ● git commit --amend - change commit at HEAD of current branch Iterate until you have added all changes
- 17. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Demo 1: Starting a repo
- 18. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Working on branches ● Branches can be just local ● Very fast to create ● Very fast to switch between ● Very convenient for working ● Modular changes ● Consist of one or more commits ● Can be “moved around” ● Default branch is “master”, like the main trunk of the repository tree
- 19. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Branches ● git branch - show all branches in your repo (* star on you current branch) ● git branch <name> - creates branch (but not checked out) ○ Pro tip: follow a good and clear name system that describes the feature you’re developing. If you are carrying out different independent changes, think of creating different branches and switch between them. If you’re working with other people it can be useful to use the (?) name/feature (i.e., violeta/data_validation) ● git checkout <branch_name> - checkout to branch ○ Pro tip: git checkout -b <name> - will create the branch AND checkout to it in one
- 20. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Merge Once your changes are tested and the history on your branch is clean, we can incorporate them to the main branch “master”. ● git checkout master ● git merge <branch> - merges branch ONTO master ○ You merge a branch onto your current branch, doesn’t have to be master. Make sure you check what your current branch is!! NOTE: This can cause merge conflicts. DON’T PANIC git status will tell us what to do
- 21. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Demo 2: Branch and merge
- 22. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Merge conflicts ● They can occur when we try to modify the same line in two different ways ● git status - shows which file has the conflict ● Edit file: ○ You can keep the current changes ○ You can keep the old changes ○ Or you can modify them to look how you like
- 23. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Revisions Revisions are revised versions of our code. Each commit represents a revision of our code. ● git checkout <commit> - checkout a specific revision of our code. We are in a ‘detached HEAD’, we are not in a branch any more. ● We can make experimental changes, build or test our system without impacting any branches. ● git checkout -b <name> - if we want to save the new commits in a branch or ● git checkout <previos_branch> - to go back to where we were ○ Pro Tip: you can also use ‘git checkout -’
- 24. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Stash If we have uncommitted changes in our index and we want to checkout a different revision, they may go into conflict! ● git stash - stashes all changes “away”, leaving a clean working directory ● git stash list - shows all stashed changes ● git stash apply - to restore the changes you saved ● git stash pop - apply changes AND remove them from the list
- 25. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Resetting revision ● git reset <commit> - set your current revision and index area to a certain state ○ --mixed - Resets index but not working tree. Sets HEAD to commit, discards all history, changes are kept in working tree. (default) ○ --soft - Leaves index and working tree untouched. Sets HEAD to commit, discards all history, leaves changes staged for commit ○ --hard - Resets both index and working tree. Resets HEAD, history AND working tree. You lose all code!!!
- 26. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Demo 3: stash and reset
- 27. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Rebase Rebase is used to integrate history from one branch into another branch. History is rewritten, we want to rewrite it to make it better! ● You have a working branch ● Someone else pushes to master in the remote repo ● You want to push your changes, but they may conflict with the remote repo ● You want to update the repo to reflect the other person’s changes
- 28. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Rebase ● git rebase <branch> - rebases your current branch over branch. All commits from branch are now in your history. ○ git checkout branchA ○ git rebase master There may be conflicts (because we may have changes that apply to places that are different now due to the new commits!) BUT
- 29. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk
- 30. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Resolve conflicts ● git status will tell you which files are in conflict! ● Make relevant changes ● git add <your changes> ● git rebase --continue If we changed our minds: ● git rebase --abort
- 31. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Demo 4: Rebase and solve conflict Note: commit SHAs change, as history has changed
- 32. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Interactive rebase ● More flexible rebase ● Useful for: ○ Integrating changes from code review ○ Making history simple and linear ○ Making every point in history valid ○ Making sure commits don’t undo each other ○ No “oops” commits
- 33. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Interactive rebase ● git rebase -i <commit> - rebase all commits newer than <commit> Opens a list of commits with options to modify, reorder or delete them: ● p (pick) - leave as is (default) ● r (reword) - change message ● e (edit) - modify contents of commit ● s (squash) - combine with previous commit CAREFUL: rebase is destructive. Make sure you in the correct branch, and back up!
- 34. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Splitting commits ● Mark commit for edit ● git reset HEAD^ - reset log to previous commit leaving changes in tree ● git add -p ● git commit ● Repeat until done ● git rebase --continue
- 35. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Demo 5: Interactive rebase and split commit
- 36. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Debugging ● git blame <file> - shows the commit that introduced each line of a file. ● git bisect - Amazing debugging tool. Prompts you to give a good and a bad commit, then uses a bisecting algorithm to checkout commits in between. You then run your test and mark the commit as good/bad. After a few iterations git tells you which commit introduced the bug!! Magic
- 37. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Debugging ● git blame <file> - shows the commit that introduced each line of a file. ● git bisect - Amazing debugging tool. Prompts you to give a good and a bad commit, then uses a bisecting algorithm to checkout commits in between. You then run your test and mark the commit as good/bad. After a few iterations git tells you which commit introduced the bug!! Magic
- 38. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Debugging ● git blame <file> - shows the commit that introduced each line of a file. ● git bisect - Amazing debugging tool. Prompts you to give a good and a bad commit, then uses a bisecting algorithm to checkout commits in between. You then run your test and mark the commit as good/bad. After a few iterations git tells you which commit introduced the bug!! Magic
- 39. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Debugging ● git blame <file> - shows the commit that introduced each line of a file. ● git bisect - Amazing debugging tool. Prompts you to give a good and a bad commit, then uses a bisecting algorithm to checkout commits in between. You then run your test and mark the commit as good/bad. After a few iterations git tells you which commit introduced the bug!! Magic
- 40. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Ranges ● git diff <commit2>..<commit4> - shows all changes between two commits (older..newer) ○ git diff <commit2>..HEAD - all changes from commit2 until present ● git log <commit2>..<commit4> - shows all commits between commit2 and commit 4
- 41. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Remotes ● Remotes are repositories that are backed up in some server (e.g. GitHub ) ● Use for collaboration and backup ● git clone <URL> - retrieves a repository into a directory ○ ssh://[user@]host.xz[:port]/path/to/repo.git/ ○ git://host.xz[:port]/path/to/repo.git/ ○ http[s]://host.xz[:port]/path/to/repo.git/ git is the baaeest
- 42. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Remotes ● You can have several remotes. Default is origin. ○ e.g., If you want to make changes to a repo that you don’t want to be public ● git add remote <name> <remote> - adds a new remote ● git checkout <remote>/<branch> - checks out a branch from a specific remote ● git remote -v - show tracked remotes ● git rename <old> <new> - change name of remote $ git remote -v origin gitlab@gitlab.eps.surrey.ac.uk:violeta/mystery-project.git (fetch) origin gitlab@gitlab.eps.surrey.ac.uk:violeta/mystery-project.git (push) upstream git@github.com:alex/mystery-project.git (fetch) upstream git@github.com:alex/mystery-project.git (push)
- 43. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Remotes ● git fetch [<remote>] - retrieves all references, doesn’t modify working copy ● git pull [<remote> [<branch>]] - retrieves all changes from remote into your local branch (default: origin, master) ● git push [<remote> [<branch>]] - pushes your local changes to branch in remote Attention!! Pull can create conflicts
- 44. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Demo 6: Remotes
- 45. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk If everything else fails…
- 47. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Reflog Git keeps track of every single branch change, and stores it in the Reference Log ● Each change is an entry in the reflog with a reference ● The state can be restored to any reference ● If you mess up… just reset it back to before it happened! ● Only local ● git reflog - list all entries ● git reset <sha1> Rebase Pull
- 48. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Demo 7: Reflog
- 49. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Resources ● Documentation: https://git-scm.com/ ● git <command> --help ● Man pages: ○ man git-log ○ man git-add ○ etc ● Stackoverflow is your friend ● Special thanks to Alan Ott’s talk Git like a Pro: https://youtu.be/H2annVAHKPE?t=19199
- 50. Violeta Menéndez González v.menendezgonzalez@surrey.ac.uk Thank you!!! ● Next Monthly Mini Hack in June - to be announced