Browsed by
Tag: version-control

Practical Git

Practical Git

This is a discussion on Git, the version control system. It is intended for folks with:

  1. Limited or no knowledge of any version control system
  2. Experience with Centralized Version Control Systems
  3. Experience with DVCS, but specifically git.

It covers the basics of version control, DVCS, and then goes on to describe Git in a practical way, with exercise to get the team quickly started on using Git.

It also talks a bit about how Git works internally, giving insights into the .git directory in each repository in order to demystify the commands.

It then moves on to Git workflows usable for various teams and also covers a one-line glossary of terms a person is most likely to encounter when using Git via CLI or through any UI tool.

Text Transcript

Slide 1:   Practical Git
Introduction (And Beyond)
                          @nikhilwanpal | NikhilWanpal


Slide 2: Version Control
 (The non-developer way)
                         @nikhilwanpal | NikhilWanpal


Slide 3:                       “With review comments from Guide”
                      “Modifications based on new
                      comments”
                      “Changes for team presentation”
                      “Changes for presentation at
                      conference, for novice audience”
                      “Merged changes: team and
                      conference”
                      “Cosmetic changes”
Version Control
  (The developer way)
                                       @nikhilwanpal | NikhilWanpal


Slide 4: Version Control Systems
Types:
1.  Local
2.  Centralized (CVCS): svn, cvs
3.  Distributed (DVCS): git, mercurial
                                       @nikhilwanpal | NikhilWanpal


Slide 5: Once upon a time..
● There was a Linus
● Then came Linux
● Then came the interest of the community and contributor boom
● Contributors distributed through time and space.
● The central person would become overworked, loaded.
● Need for distributed management.
● (skipping some events..) Birth of Git: To handle far complex, large and distributed
  teams. (than us)
● ..and then, came the interest of the community and contributor boom… (git
  uses git to version control git!)
                                                                     @nikhilwanpal | NikhilWanpal


Slide 6:                 CVCS                         Vs                   DVCS
1. Central Server, that manages the truth.      1. Distributed, no single location of truth.
2. Clients do checkout snapshots.               2. All clients are mirrors; servers; truth.
3. Weak clients                                 3. Fully functional clients
4. Server needs tending to: backups,            4. Self maintaining, recoverable from mirrors;
   maintenance etc.                                (of course should have backups.)
5. File locking / conflict handling.            5. No Locking; conflicts are less frequent.
6. Constant connection required.                6. Connection required only when sharing.
7. Defined workflow.                            7. Highly flexible workflows possible. With
8. Restricts free development of open source       subteams and sharing and merging before
   projects.                                       final publishing.
                                                8. Promotes Open Source development.
                                                                             @nikhilwanpal | NikhilWanpal


Slide 7: Understanding Git (coming from a world of CVCS)
● It is distributed: Things appear to be two step.
● Think of ‘torrents’, P2P networks. (It’s not a P2P and won’t help you download GOT!!)
● Like installing your own SVN server that can communicate with other SVNs.
● Branching is dirt cheap; not a task.
● Merging is easy; not an activity. (If you know what you are merging!)
● It’s not difficult, just different. (unless our glass is full)
                                                                      @nikhilwanpal | NikhilWanpal


Slide 8: Git Hosting
●  GitHub Vs GitLab Vs BitBucket
●  Git : GitHub = water : packaged drinking water
●  All hosting providers add proprietary features to git, ex: pull request.
●  Hosting providers do, can provide other VCS as well.
●  Git does not need hosting, or server or background process
●  Git can work with a shared folder as remote
●  Hosting makes corporate workflows easy
                                                                     @nikhilwanpal | NikhilWanpal


Slide 9: Your Git
● Install Git
● Setup
  git config --global user.name "Nikhil Wanpal"
  git config --global user.email "nikhil@dontwasteyourtimereading.com"
                                                                       @nikhilwanpal | NikhilWanpal


Slide 10: Your Git, Your First Repository
In a new directory: practical-git/1/
 ●   git init
 ●   Create file, git add, git commit -m
 ●   Modify file, git add, git commit -m
 ●   git log
 ●   Modify file, git add, git commit --amend
 ●   Modify file, git add
 ●   git reset
                                              @nikhilwanpal | NikhilWanpal


Slide 11: Your Git, Your First Repository with a server
In a directory: practical-git/central-repo.git/
      ●   git init --bare
In a directory: practical-git/personal-repo/
      ●   git clone ../central-repo.git/ .
      ●   git add
      ●   git commit -m
      ●   git push
                                                @nikhilwanpal | NikhilWanpal


Slide 12: Your Git, Your First Repository with a server and a
dual personality
In a directory: practical-git/central-repo.git/
      ●   git init --bare
In a directory: practical-git/personal-repo/
      ●   git clone ../central-repo.git/ .
      ●   Create file, git add, git commit -m
      ●   git push
                                                @nikhilwanpal | NikhilWanpal


Slide 13: Your Git, Your First Repository with a server and a
dual personality (v1)
In a directory: practical-git/colleague-repo/
      ●   git clone ../central-repo.git/ .
      ●   Surprise!
      ●   Create file, git add, git commit -m
      ●   git push
In a directory: practical-git/colleague-repo/
      ●   git pull
                                              @nikhilwanpal | NikhilWanpal


Slide 14: Branches and Tags
                  reviewComments
                  presentation4Team
                  V1
                  V1.1
                             @nikhilwanpal | NikhilWanpal


Slide 15: V1.1 Branches
● Threads of development
● String of thought
● Series of changes with similar purpose
● A diversion
  git branch myFirstBranch
● Create a file, git add, git commit -m, git push
  git checkout master
                                                  @nikhilwanpal | NikhilWanpal


Slide 16: V1.2 Merges
● Tie the threads together
● Bring together different thoughts and ideas
● Achieve the purpose of your branch
  git merge myFirstBranch
● Git’s intelligent merge
  git checkout myFirstBranch, modify line 1, push
  git checkout master, modify line 2, merge
                                                  @nikhilwanpal | NikhilWanpal


Slide 17: V1.3 Conflicts
● What happens when two different lines of thought try to merge?
● Branches need a judge!
● You!
  git checkout myFirstBranch, modify line 2, push
  git checkout master, modify line 2, merge!
● Now try that across repositories, you have 2.
                                                              @nikhilwanpal | NikhilWanpal


Slide 18: V1.4 Rebase
 ●   Rewriting history
(after same steps as a conflict..)
     git pull origin master --rebase
                                     @nikhilwanpal | NikhilWanpal


Slide 19: What is a:
● Git commits storage: a rooted, Directed Acyclic Graph of patches.
● Patch: the delta between two commits. (or more)
● Staging/Index: Selecting relevant changes for commit.
● Commit: The delta store in git filesystem with name as the SHA.
● Branch HEAD: A pointer in the graph for ease of access.
● Branch: The path from root to branch head.
● Stash: Stash aside the state for now.
● HEAD: a variable, a pointer to current pointer of the current branch.
● Detached HEAD: state of repository when a commit is checked-out, which is
  not pointed to by any of the HEADs
                                                                 @nikhilwanpal | NikhilWanpal


Slide 20: What is a:
● Merge: Delta from the ‘common ancestor’ added together.
● Fast - Forward Merge: Pointer updated to the latest head.
● Merge commit: the commit that identifies a merge.
● Rebase: Rewrite the history to change the branching point, and reapplying
  the changes over. No more the same commits. (creating new history is that easy..!)
● Reset: undo, hard vs soft.
● Remote: The different repositories, tracked branches, not same branches.
● Pull: fetch + merge (rebase!)
                                                              @nikhilwanpal | NikhilWanpal


Slide 21: Git Folders:
 ●   HEAD: pointer to current branch’s head
 ●   index: staging info
 ●   refs: commit objects. Basically branch data.
 ●   objects: blobs of files and tree objects.
Git Objects:
 ●   blobs: or git objects contain the contents of checked files. Key-value file
     storage.
 ●   trees: pointers to blobs by filenames and other trees.
 ●   Commit: top level tree, user, additional info regarding commit, message etc.
 ●   Packfiles and git gc | auto gc.
                                                                    @nikhilwanpal | NikhilWanpal


Slide 22: To Branch or not to branch..
What is a branch? (There is no such thing as a branch! It’s the path from the head to root,
traversed through ‘parent’ pointers.)
Git References:
       ○   Branches
       ○   Tags
       ○   HEAD
       ○   Remotes
Are you coming back to it? Then you need a branch!
                                                                            @nikhilwanpal | NikhilWanpal


Slide 23: Git Flow
●  A branching model suggested by Vincent Driessen in his blog.
●  develop and master: The only long lived branches.
●  Features, Releases and Hot-fixes
●  Convention: feature/; release/ and hotfix/
●  Life-cycle of:
    ○   Feature: develop → develop
    ○   Release: develop → (master + tag | develop)
    ○   HotFix: master → (develop + master(tag?))
                                                              @nikhilwanpal | NikhilWanpal


Slide 24: Git Shortcuts
Bash / shell aliases:        Git aliases:
 ●  alias gs='git status '    ●   git config --global alias.st status
 ●  alias ga='git add '       ●   git config --global alias.a add
 ●  alias gc='git commit'     ●   git config --global alias.ci commit
 ●  alias gb='git branch '    ●   git config --global alias.br branch
 ●  alias go='git checkout '  ●   git config --global alias.co checkout
                                                    @nikhilwanpal | NikhilWanpal


Slide 25: Git Best Practices
●  Commit often (every 30 mins), push once. Clean-up before push.
●  Prefer to code on new branch locally, never push such branches. Share
   among developers but not to central.
●  One change per commit. Not more.
●  Describe the commit well.
●  Consider rebase before push or pull, follow up with a --no-ff commit.
●  Don’t break the development tree.
●  Review merges. Build and fix post a merge before push.
●  Avoid force-delete (-D) when deleting branches.
●  Consider using shortcuts/aliases.
●  NEVER rebase pushed commits.
                                                                  @nikhilwanpal | NikhilWanpal


Slide 26: }
  @nikhilwanpal | NikhilWanpal

Using the link below, you can also download the PDF file for offline reference. Although, I prefer to revisit and update my presentations, you can always refer to the latest version here.

[TechNggets] Episode 2: Intro to Git Flow

[TechNggets] Episode 2: Intro to Git Flow

This is the second episode of podcast “Tech Nuggets and Thoughts”.

 

Some docs on git flow:

  1. The blog that brought it to us: http://nvie.com/posts/a-successful-git-branching-model/
  2. git flow scripts project discussed in podcast: https://github.com/petervanderdoes/gitflow-avh
  3. A superb cheat sheet for git flow: https://danielkummer.github.io/git-flow-cheatsheet/

 

To get updates, you can subscribe to the podcast on: Apple iTunesplayer.fmRSS feed. If you have any suggestions, thoughts or recommendations, please feel free to comment below. You can also reach me on podcast’s twitter handle @TechNggets or my personal account @nikhilwanpal.

(If the fancy player above does not work, try the bare bones player below.)

Creating a Local Version Control System

Creating a Local Version Control System

Now this is a post that is going to be updated time and again.. The very post that made me abandon my previous blog to move on to a Google site..

Requirement:
Need to setup a local repository.. a version control system.. Given that I use VSS (I know, please dont make faces..!) at my work place, I am used to the ‘ease’.. However it may be, it sure is simple to use…! I need the repository to be platform independent, as I dual boot into Windows 7 and Ubuntu, secondly need it to be local.. Now thats the background, next is a journal…
Which one to use?
Tried:
CVS: on Ubuntu 11.4 and on windows 7.. dint find it so impressive..
TortoiseCVS: Dont know why but the options in the context menu never appeared…! :S
Mercurial: confused about its use.. yet to be tried..
Trying out git.. many friends suggest this.. seems interesting.. simple to learn, they say.. lets see!
Git setup
Alright, what helped me understand it whole was two great articles, one form tiredblogger and another from a harvard site.
Do go through them both… (And you don’t have to read this page any further! 🙂 )
Rest is for my reference, for my own understanding..
It was simple to setup..
Download and install git from the ubuntu download center… Download and install git for windows from Google code project.. Done.. Both OS set.
In windows, left almost all settings unchanged during installation..
All I need to do is to create a bare repository to start with, its better they say.. so
in a new folder:

git init --bare

Then clone it into a new repo.. That’s the working folder I guess…
so..

git clone <prev folder> <new folder name>

Done..
Then create and add new file to this new folder.. Thats the first source file..
Then, add it to repo..

git add .

Commit the repo..

git commit -a -m "a message"

Push the updates to the main repo, which would otherwise have been a remote repository, the original one from which the working was cloned.

git push origin master

Cool enough.. Lets try new things..

Working on multiple OS
The local repository cant be directly used from both the OS.. so What I am gonna have to try is to work as if I am 2 different persons contributing to a project.. haven’t very well understood it all yet! lets see…!

Change only the origin url!

Alright.. Now, all I need to do is change only the path / url in the git config file for the head origin! Once done, the push was fine…! 🙂 so…
Is there a way to avoid this manual work???
like having 2 origins? remotes I mean..
In manual it is said that the remote path can also be passed from a file in $GIT_DIR/remotes
But does that create new branches? If so, that’ll clutter the repository unnecessarily…
lets see…

This post will be updated as and when I learn new things..!