Use git efficiently
Know common use cases [ internal case in Incorta ]
Know widely used git workflows
traditional vcs - keeps track of diffs
git - takes snapshots of all the structure
Untracked
Tracked [ Modified / Newfile ]
Staged
Commited
and all of these are local
Whatever the tool you use it should at least support
Basic git operations
Viewing the log and the branch tree
And please don't use git-hub's client
List of available clients: http://git-scm.com/download/gui/
you can try them at: https://try.github.io
[ tracked or untracked ]
[ file is still there in the directory ]
i/a to edit
esc switch back to command mode
:wq to write and quit
git checkout <branch>
git checkout -b <new_branch>
git checkout [branch] -- <file / path>
Join two or more development histories together
You can have
FF Merge
True Merge
Conflicts :'(
cherry pick commits from branch to another branch
The golden rule: never rebase a public branch
We'll get to that soon enough
Are versions of the repository that are hosted on the somewhere else.
Supported protocols: SSH / HTTP / File system
is just a a default naming convention
clones a repository from remote to current dir
it adds an "origin" remote by default
shortcut to [ init , remote add .. , git pull ]
upstream remote branches
vs
local remote branches
synchronize local remote branches with upstream remote branches
shortcut to [ fetch , merge <remote>/branch ]
an optional --rebase flag uses rebase instead of merge
pushes changes to upstream
always specify the remote and branch name
git fetch origin
git pull origin master
git push origin development
cherry pick
log
diff
tag
squash, interactive rebase
instead of inputting your username/password every time
invest some time in learning the tools available to your platform
Eclipse / Webstorm / Webstorm
gitg / gitX
vim
to manually edit some git configs
If you do it a lot, try to automate it
chances are you might find a shortcut command to do it
or alias it
all changes are committed to master
before publishing developer rebases his changes
create a branch for each feature
merge with master when feature is done.
master - official release
dev - stage merging the features together
after some features you go to release branch
after preparing release you merge with master
hotfix branches forked from master then merged to master and develop
Each has a forked repository
do wahterver u want with it ,
A maintainer mergers their changes togeter in the official repository
Text
Code history remains flat and readable.
Manipulating a single commit is easy
Rebasing can be dangerous! Rewriting history of shared branches
It's more work
you need to force push at some point.
Traceability
History can become intensely polluted by lots of merge commits
At some point some one is responsible for your changes
relating features / changes together
not needing multiple pull requests
huge number of files slows down git
minor fix/changes affects all other projects