2. Scope
• Just a soft introduction.
• Introduces you to terms and best practices.
• Hands-on.
• But you should practice !
3. Why Git
“A good developer is also
good at code management.”
• Simple to work with.
• Non linear development and distributed development.
• Fast and robust.
• Manages complex code merges.
4. Baby steps
3 magical ways to learn git
• Always use command line.
• Always use command line.
• Always use command line.
because with GUI you never get hands-on !
5. Lets speak the same language
commit
• A snapshot of code change.
• Captures what, who and when changed.
• Commit id is unique to your repository.
commit 86da7a8dd0be71842744fc8aadf3dc5ced28f3dd!
Author: Srikanth Sombhatla <srikanth@zippr.in>!
Date: Thu Nov 6 16:02:11 2014 +0530!
!
improved subscription sync. fixed issues and
minor refactorings
6. Lets speak the same language
branch
• A chain of commits.
• In the context of branch of development
• Topmost commit of the branch is called HEAD
• Use HEAD to reset the branch incase of any issues.
• You loose all your changes !!
git branch!
Dev!
inplace_zoom!
inplace_zoom_i2!
perf_async_loading!
* pictures!
rel_indian_summer_1.8.2!
7. Lets speak the same language
repository
• A working tree. Completely self contained.
• The collection of your code and their branches.
• In server this is called remote repository!
• On local machine this is called local repository!
• You clone a remote repository!
• You init a local repository
8. Lets speak the same language
clone
• a remote repository reflected in your local.
• actually you are following that git repository.!
push
• All local commits uploaded to remote
pull
• All commits downloaded to local!
11. What is a good commit?
• One commit - One change.
• This can have multiple files relevant to one change.
• Never combine multiple irrelevant changes into one commit.
• Because you cannot rollback a particular change.
• Because it is difficult to do code review.
• Because it is just not clean.
• Your commit message should be self explanatory.
12. Commit work flow
• Make sure you are in the correct branch
• git branch
• Check status
• git status
• Review your changes - is this what you want to commit ?
• git difftool
• any standard tool like opendiff can act as git difftool
• git commit
• Once done these changes are committed to staging.
13. Branching strategy
• One feature - one branch.
• Ex: pictures, performance, bugfixes etc
• All code changes for this feature are confined to this branch.
• You work independently.
• Anytime switch to another branch. Revisit and continue your work.
15. Release strategy
• One production release - one branch.
• After release freeze this branch and never push anything
upstream.
• Reference code in future.
• Helps in applying hot fixes