Git Basics walkthough to all basic concept and commands of git

git basiscs

1. secret sauce
Violeta Menéndez González
[email protected]

2. Violeta Menéndez González [email protected]
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 [email protected]
What is git?
Distributed instead of centralised:
●Each user has a full copy of the repo

4. Violeta Menéndez González [email protected]
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 [email protected]
What is git useful for?

●Reproducibility

●Collaboration

●Debugging

6. Violeta Menéndez González [email protected]
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 [email protected]
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 [email protected]
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 [email protected]
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 <[email protected]>
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 [email protected]
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 [email protected]
Workflow
●Work in branches (feature branches)
●Main branch (master) for tested and clean changes

12. Violeta Menéndez González [email protected]
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 [email protected]
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 [email protected]
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 [email protected]
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 [email protected]
Demo 1: Starting a repo

18. Violeta Menéndez González [email protected]
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 [email protected]
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 [email protected]
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 [email protected]
Demo 2: Branch and merge

22. Violeta Menéndez González [email protected]
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 [email protected]
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 [email protected]
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 [email protected]
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 [email protected]
Demo 3: stash and reset

27. Violeta Menéndez González [email protected]
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 [email protected]
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 [email protected]

30. Violeta Menéndez González [email protected]
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 [email protected]
Demo 4: Rebase and solve conflict
Note: commit SHAs change, as history has changed

32. Violeta Menéndez González [email protected]
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 [email protected]
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 [email protected]
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 [email protected]
Demo 5: Interactive rebase and split commit

36. Violeta Menéndez González [email protected]
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 [email protected]
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 [email protected]
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 [email protected]
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 [email protected]
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 [email protected]
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 [email protected]
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 [email protected]:violeta/mystery-project.git (fetch)
origin [email protected]:violeta/mystery-project.git (push)
[email protected]:alex/mystery-project.git (fetch)
[email protected]:alex/mystery-project.git (push)

43. Violeta Menéndez González [email protected]
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 [email protected]
Demo 6: Remotes

45. Violeta Menéndez González [email protected]
If everything else fails…

47. Violeta Menéndez González [email protected]
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 [email protected]
Demo 7: Reflog

49. Violeta Menéndez González [email protected]
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 [email protected]
Thank you!!!
●Next Monthly Mini Hack in June - to be announced