CVS

1. Centralized version control system.

2. Branching/Merging is complicated.
3. When server goes down you cant commit.
4. File renames are not supported in CVS, and manual renaming might break history in two, or lead
to invalid history.
5. CVS usage merge-before-commit (or update-then-commit).
6. Commits are not atomic operation.

Git

1. Distributed revision control system.

2. With Git you can do practically anything offline, because everybody has their own repository.
3. Clone of repository - local repository that contains both the working tree and the revision
history branches and tags.
4. We can clone from any users working repository (distributed) and work on it (.git folder)
5. Because Git is a distributed system in addition to connecting to a central repository
Developers can connect to another developers repository. This allows teams to share code
without affecting the central repository.
6. Your working copy is a clone of the entire repository - This decreases the overhead (speed and
manual work) switching contexts.
7. To close just need a URL - URL in Git determines the location of the repository.
8. Branching is easy - branching takes less disk space.
9. When switching branches there is no need to connect to a remote server (local repository).
10. Merging is very easy.
11. When merging you do not need a connection to the remote server, you have all branches
locally. User can create branch locally - task feature wise then merge them.
12. Git supports renaming files also maintain history for the same.
13. In Git all operations are atomic.
14. Commit before merge - Git uses commit-before-merge rather than, like CVS, merge-before-
commit (or update-then-commit). If while you were editing files, preparing for creating new
commit (new revision) somebody other created new commit on the same branch and it is now
in repository, CVS forces you to first update your working directory and resolve conflicts before
allowing you to commit. This is not the case with Git. You first commit, saving your state in
version control, and then you merge other developer changes. You can also ask the other
developer to do the merge and resolve conflicts.

Vipin Mangalkar Git

 Using Git

1. Creating a Repository
Use git init command to create new git repository
$ git init myproject

This will create a new repository myproject.

Inside git repo you will see .git folder. This folder contains all git repo info i.e. branches, tags, etc.
The default master branch gets created.

To publish your repository to remote i.e. Push your project to remote git server
To put your repository on a server we'll start by making a "bare" repository, and upload it to a server.
To create bare repository use

$ git clone --bare myproject.git

Now to publish local repository to remote use

$ scp -r myproject.git server-name:/home/git/repo
or
$ git push --mirror ssh://server-name:/home/git/repo

Notes: bare git repository

A bare repository created with git init --bare is for sharing. If you are
collaborating with a team of developers, and need a place to share changes to a repo,
then you will want to create a bare repository in centralized place where all users
can push their changes. Because git is a distributed version control system, no one
will directly edit files in the shared centralized repository. Instead developers
will clone the shared bare repo, make changes locally in their working copies of the
repo, and then push back to the shared bare repo to make their changes available to
other users.

2. Cloning Repository

To clone remote repositories use git clone command

$ git clone git:/home/git/repo/myproject.git # git server path

Now you have local working repository

Your local working repository consist of three trees
i. Working Directory which holds data files
ii. Index stage area
iii. Head which points to the last commit

Vipin Mangalkar Git

3. Creating and Adding Files

When we create files inside local repository we need to add this file to stage.
If file not added in stage then git consider it as untracked file.

To check untracked, un-committed file and current git repository status use
$ git status

To add files to stage use

$ git add file-name.extention # add single file
$ git add . # (.) Period will add all changed files.

Now your added files are ready to commit. So commit the files using
$ git commit m commit message

If you have to do both add and commit in one go use

$ git commit -a m "Changed some files"

To check commits logs use

$ git log
$ git log --pretty=oneline # single line log for every commit

Notes:
Everything whatever we are doing is on local repository (add/commit)
We need to push those changes later to remote repository.

4. Pushing Changes to remote repository

To push your local repository committed changes to remote git repository use

$ git push origin master #Here master is our current working branch

Vipin Mangalkar Git

5. Branching

Branches are used to develop features isolated from each other.

The master branch is the "default" branch when you create a repository.
Use other branches for development and merge them back to the master branch upon completion.

To show all branches use

$ git show-branch

To creating branch use

$ git branch branch-name

To checkout branch
$ git checkout branch-name

In single go creating and checkout branch use

$ git checkout b branch-name

To delete branch use

$ git branch d branch-name

Notes: To switch between branches use $ git checkout branch-name command

Branch is not available to others unless you push the branch to your remote repository
To push branch to remote use
$ git push origin branch-name

6. Update your local repository from remote latest changes

To updates or get latest changes from remote repository to local use

$ git pull # git pull does both git fetch and git merge in one go

Vipin Mangalkar Git

7. Git Merge

Merge branches - suppose you are working on dev branch and all development for the module is
done and now you want to put that code into your uat branch then use

$ git checkout uat # switch to uat branch

$ git pull # pull the changes from uat branch
$ git merge dev # merged your dev code to uat

Now you have merged your dev branch changes to uat branch (local repository)

To move that changes on remote git server uat branch use

$ git push origin uat

Notes: Before merging changes, you can also preview them by using
$ git diff <source_branch> <target_branch>

8. Using Stash -

When moving between branches your local changes move with you. Sometimes you want to switch
branches but not commit or take those changes with you. The Git command stash lets you put
changes into a safe store.

To stash use
$ git stash

To retrieve that changes when required use

$ git stash apply

9. Replace local changes (revert current local changes)

In case you did something wrong, which for sure never happens, you can replace local changes using
$ git checkout -- <filename>

Vipin Mangalkar Git

10. Tagging

Listing Your Tags (Already Tagged Version) use

$ git tag

Creating Tags

$ git tag -a tagVersion -m "tag comment here"

Notes:
Everything whatever we are doing is on local repository (add/commit/tag/merge)
We need to push those changes later to remote repository.

By default, the git push command doesnt transfer tags to remote servers.
You will have to explicitly push tags to a shared server after you have created them.
This process is just like sharing remote branches

$ git push origin [tagname]

11. Logs
$ git log -author=author-name #To see commits of certain author

$ git log --pretty=oneline #compressed log where each commit is one line

# to check no of files in commit using commit hash

$ git diff-tree --no-commit-id --name-only -r bd61ad98

#here bd61ad98 is commit hash

12. Miscellaneous
Git has a stage area, git add will places the files in this area.
Everything whatever we are doing is locally we need to push that remote manually.
Commit hash commit hash is addressable via a hash (SHA-1 checksum).
This hash is calculated based on the content of the files, the content of the directories,
the complete history of up to the new commit, the committer, the commit message, and
several other factors.

Vipin Mangalkar Git