There are many number of Subversion Vs Git comparisons around the web and most of them are based on myths rather than facts. In this article, we will explain you the major differences between these version control systems to help you to understand the actual state of affairs.

Distributed Nature

Git was designed from the ground up as a distributed version control system. Version control system means that multiple redundant repositories and branchings are the first class concepts of the tool.

In a distributed VCS like Git every user consists of a copy of the repository data stored locally, thereby it gives the user to access the file history and also allows full functionality when disconnected from the network.

In a centralized VCS like Subversion, only the central repository has the access to view the complete history. This means that user must communicate over the network with the central repository to obtain history about a file.

Branch Handling

Branches in Git are the core concept used on every day by every user. In Subversion they are more unmanageable and often used sparingly.

In Git, developers working directory is itself a branch. If two developers are modifying two different unrelated files at the same time, it is easy to view those directories as different branches stemming from the common base revision of the project.

Speed of Operation

Git is extremely fast. All the operations are local and there is no network latency involved for the following.

View file history
Commit changes
Merge branches
Switch branches
Switch branches

Line Ending Conversion

Subversion can be easily configured to automatically convert line endings for CRLF or LF, depending on the native line ending used by the clients operating system. Subversion also allows the users to specify line ending conversion on a file-by-file basis. If the user does not check the binary flag on adding binary content, then the content might get corrupted.

Single Repository

Subversion only supports a single repository. Only the user knows the repository URL and all the materials and the branches related to that project.

Since Git is distributed, not everything related to the project can be stored in the same location.

Data Storage

Every control system stores the metadata of files in hidden folders like.svn, .cvs and much more. Whereas, Git stores the entire content in the .git folder. If you are comparing the size of .git folder with .svn, you will notice a huge difference. The .git folder is the cloned repository on your machine, it has everything that the central repository has such as, tags, branches, and version histories.

Access Control

Subversion has a single central repository, it is possible to specify read and write access controls in a single location and can be executed across the entire project.

Change Tracking

In earlier versions of Git, there are only minor changes to binary files such as adjustment of brightness for images which is different because Git interprets them as a new file making the content history to split. The Subversion tracks file-by-file hence, history for changes is maintained.

The post GIT VS SVN appeared first on Pro-Tek Blog.

Are you new to GIT? Then you will recognize some things which work differently as compared to SVN or CVS based repositories. In this article, we will explain you the top 10 important GIT commands in a GIT workflow that you need to know about.

Are you using Windows? Then set-up Git on your local machine to follow the steps below.

The GIT workflow as follows

Go to the directory where you want to have the version control. Use git init to keep the directory under version control. This creates a new repository for the current location. The user can make changes to their files, and can use git add to stage files into the staging area. The user can also use git status and git diff to see what exactly the user has changed. When you want to upload the changes to a remote repository then you need to use git push.

When the user wants to download the changes from a remote repository to the local repository the user needs to use git fetch and git merge.

1. Git auto complete:

The auto complete feature can be enabled for git commands and it works in internal terminal.
For implementing that, you need to edit the bash_profile file.
sudo nano ~/.bash_profile
and add the following lines.
if [ -f ~/.git-completion.bash ]; then
. ~/.git-completion.bash
fi

2. Track the file changes:

In order to keep things in control and to know who is responsible when something goes wrong, it is always useful to see all the changes done to a particular file or files. A user can do this easily by using git blame command, which will show the author for every line in a file.

git blame my_filename

3. Stash uncommitted changes:

The stash command saves the user’s time in the situations where the user needs to show his applications to the client or someone from the management team. Since the user is in the middle of the work and the application would not work without reverting the changes. At that point, a user can run the stash command, which saves all the changes for further usage.

git stash

A user can showcase the work without losing any progress. When the user wants to see the list of stashes, then run:

git stash list
To recover the uncommitted changes, execute the following command:
git stash apply
It is also possible to retrieve a particular stash only:
git stash apply stash_unique_id

4. Staging parts of a changed file for a commit:

According to the best practices, while using version control, each commit should represent either a feature or a bug fix. However, team members or a user can add multiple features or can fix multiple bugs without committing. In such sought of situations, a user can stage files individually and commit them separately.

git commit -p myfilename

5. Clone a specific remote branch:

In some cases, the user doesn’t want to clone the entire remote repository, but only one of its branches. A user can perform that by running the following command.

git remote add -t Mybranchname -f

6. Delete a remote branch:

Deleting a remote branch is more confusing than deleting a local one. In newer versions of git, a user can use the following command.

git push origin –delete Mybranchname

However, in previous versions, user had to use push “nothing” to the branch in order to delete it.

git push origin :Mybranchname

7.Merge current branch with a commit from the other branch:

When the team is working in parallel with multiple branches, the change made in one branch has to be applied for the other branches. Using the cherry-pick command, a user can do it by merging a single commit from the other branch into the current branch, without changing other files or commits. So, the First switch to the branch that the user has to merge with the commit and then run the cherry-pick command.

git checkout Mybranchname

git cherry-pick commit_hash

8. Pull with rebase instead of merge:

When the team members are working on the same branch, the user has to pull the code and merge changes frequently. To avoid merge messages from cluttering up the log, use the rebase.

git pull –rebase

Also, user can configure a certain branch to always rebase:

git config branch.mybranchname.rebase true

9. Use .gitignore and .gitkeep:

In git, it is possible to exclude some files from version control. This is done by creating a file named .gitignore in the root of the project. After that, add the path to each file in a new line. The git automatically skips the empty folders by default. If the user wants to commit an empty folder, create a .gitkeep file and place it in the folder.

10. Change the default message editor:

In UNIX operating system, the default editor for commit message is VI. If the user wants to change it, the user can run the following command.

git config –global core.editor “path/to/my/editor”

The post TOP 10 COMMANDS OF GIT appeared first on Pro-Tek Blog.