Wednesday, 12nd of October, 2016
- multiple backups
- fast operations
- works offline
- paradigm shift compared to CVS, SVN
- designed for multiple branches
- easy context switching
- enable a lot of workflows
git: (very) basic usage - 1
- default branch is called 'master'
git: (very) basic usage - 2
(and git objects in general)
by SHA-1 hashes
Use a graphical tool for commits !
git: (very) basic usage - 3
Use a graphical tool to look at your repository
Useful git commands - 1
helps recovering from (almost) any situation: lost commits recovery, undo...
Useful git commands - 2
search for commits adding or removing 'something'
... also works with 'gitk' :)
syntax: git diff branchA branchB -- path to file
Useful git commands - 3
Usage: applying a bug fix from a branch to another one, without getting all changes introduced by commits from this branch
Ready for more advanced stuff ?
A word about HEAD
command above removes all uncommitted changes (but it doesn't delete untracked files - see 'git clean' for this !)
advice: commit often, commit early to avoid uncommitted changes
you can squash your X latest commits into one using
'git rebase -i HEAD~X'
ACHTUNG: only for commits you didn't share with others yet, since it is rewriting the commits history
Submodules - 1
Very convenient to guarantee the container project works, whatever happened to the submodule
Similar to subversion's Externals, in a way
When the submodule is initialized, it is in "detached HEAD" state: the HEAD is not in a branch
Submodules - 2
1. Two git repositories, HelloC and HelloPython
2. Let's create a new Hello git repository
3. Add the submodules
4. Commit the submodule update
Collaborating using remotes
- remote repositories are versions of your project located elsewhere
- can be on the internet, over a private network, or on disk
- code can be pushed to or pulled from a remote
- first remote is often called 'origin'
- this is where the code originally comes from
- ... but it is just a name, remotes can be called anything
- git clone : make a local copy of a remote repository
Remote branches - 1
Remote branches - 2
"push the commits from local branch to the origin remote, in the master branch"
'git pull' does a 'git fetch' + a 'git merge'
If remote branch tracking is enabled, it automatically merges the remote branch into the local one
We prefer rebase vs merge
BUT beware: NEVER rebase a public branch !
Configure 'git pull' to do rebase instead of merge
Our git workflow
- stable master branch
- new features in branches
- merge requests (with gitlab)
- in theory, master should not contain broken code
- facilitates Continuous Integration
- several developers can work on a new feature without disturbing the main codebase
- communication++ between developers, code review
- only 1 public repository
- pushed branches have to be merged
- source for merge request will always be from a feature branch
- destination will always be 'master' branch