Is Awesome
Goals
Use git efficiently
Know common use cases [ internal case in Incorta ]
Know widely used git workflows
!=
We use
Our git repositories are hosted on
Core git concepts
Snapshots Not Diffs
traditional vcs - keeps track of diffs
Snapshots Not Diffs
git - takes snapshots of all the structure
Almost all operations are local
File Stages
Untracked
Tracked [ Modified / Newfile ]
Staged
Commited
and all of these are local
git clients
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/
Basic Operations
you can try them at: https://try.github.io
init
creates a new repository inside a directory
add
adds a file to the stage
[ tracked or untracked ]
rm
untracks a file
[ file is still there in the directory ]
status
to see the repository status
commit
commits the staged files
commit message best practices
- First line should contain brief concise description, 50 characters or less and followed by a blank line.
-
Should include
- Why is this change necessary?
- How does it address the issue?
- Any limitations or side effects.
- Should include issue/feature id if applicable.
- A large commit message, might indicate that the commit should be split into 2 or more parts.
Message Editor - VIM
i/a to edit
esc switch back to command mode
:wq to write and quit
History / Branch Operations
Branches
checkout
switches a branch or paths to the working tree
Mostly used options
git checkout <branch>
git checkout -b <new_branch>
git checkout [branch] -- <file / path>
stash
stash away your changes
Merge
Join two or more development histories together
You can have
FF Merge
True Merge
Conflicts :'(
Rebase
cherry pick commits from branch to another branch
The golden rule: never rebase a public branch
Rebase Vs Merge
We'll get to that soon enough
Remotes
Remotes
Are versions of the repository that are hosted on the somewhere else.
Supported protocols: SSH / HTTP / File system
origin
is just a a default naming convention
clone
clones a repository from remote to current dir
it adds an "origin" remote by default
shortcut to [ init , remote add .. , git pull ]
remote branches
upstream remote branches
vs
local remote branches
fetch
synchronize local remote branches with upstream remote branches
pull
shortcut to [ fetch , merge <remote>/branch ]
an optional --rebase flag uses rebase instead of merge
push
pushes changes to upstream
A good practice
always specify the remote and branch name
git fetch origin
git pull origin master
git push origin development
Worth to mention
cherry pick
log
diff
tag
squash, interactive rebase
Productivity Tips
Use SSH Keys
instead of inputting your username/password every time
Install autocomplete scripts
Try your tools
invest some time in learning the tools available to your platform
Eclipse / Webstorm / Webstorm
gitg / gitX
vim
Use config -e
to manually edit some git configs
Automate
If you do it a lot, try to automate it
chances are you might find a shortcut command to do it
or alias it
Use the CLI more
Reminders
Workflows
Centralized Workflow
all changes are committed to master
before publishing developer rebases his changes
Feature branch workflow
create a branch for each feature
merge with master when feature is done.
gitflow
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
forking workflow
Each has a forked repository
do wahterver u want with it ,
A maintainer mergers their changes togeter in the official repository
Discussion
Versioning
Rebase vs Merge
Rebase Pros
Text
Code history remains flat and readable.
Manipulating a single commit is easy
Rebase Cons
Rebasing can be dangerous! Rewriting history of shared branches
It's more work
you need to force push at some point.
Merge Pros
Traceability
Merge Cons
History can become intensely polluted by lots of merge commits
At some point some one is responsible for your changes
Single Project vs Multiple Projects
Pros
relating features / changes together
not needing multiple pull requests
Cons
huge number of files slows down git
minor fix/changes affects all other projects