Enforce the JIRA issue id in a GIT commit message

Enforce the JIRA issue id in a GIT commit message

This can be done by using git hooks file location at .git/hooks/commit-msg. Following are the 2 way in whcih each Developers can set the Hooks in their developement envioronment.

Method – 1

# commit-msg.sh
#!/bin/sh
# This hook will make sure that the commit message contains a JIRA issue.
#
# To enable this hook, rename this file to ".git/hooks/commit-msg".
# Make sure to add execution permissions to the file.

export MESSAGE=$(<$1)
export JIRA_ISSUE_TAG='ISSUETAG-([0-9]*)'

if [[ $MESSAGE =~ $JIRA_ISSUE_TAG ]]; then
echo -e "\e[32mGreat, your commit message contains a JIRA issue!\e[0m"
exit 0;
fi

echo -e "\e[31mOh hamburgers ... You forgot to add a JIRA issue number!\e[0m";
exit 1;

Method 2 – This is another very good example to implement to force jira id in each commit message. http://nsbogan.com/tools/2015/06/04/jira-id-in-git-commit-messages

Tagged : / / / /

Best Branching and Merging strategies in Gerrit

Best Branching and Merging strategies in Gerrit

Step 1 – First Lets read this article about Best Branching and Merging strategies in git

Best Branching and Merging strategies in git

Step 2 – Now Lets learn the Gerrit Merge Types
https://nofluffjuststuff.com/magazine/2016/04/understanding_and_applying_gerrit_part_3_gerrit_submit_types_and_git_review

Step 3 – Time to Learn the Types of Submit in Gerrit
https://gerrit-review.googlesource.com/Documentation/project-configuration.html

Step 4 – Finally, You must read the recommendations below
https://hyperledger-fabric.readthedocs.io/en/release-1.2/Gerrit/best-practices.html

Tagged : / / / / /

Best Branching and Merging strategies in git

Best Branching and Merging strategies in git

Step 1 – First you need to learn the needs of branches. This is very good read.

  • https://docs.microsoft.com/en-us/vsts/repos/tfvc/branching-strategies-with-tfvc?view=vsts

Step 2 – Now time has come to Learn best branching model in Git.

  • https://buddy.works/blog/5-types-of-git-workflows
  • https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2
  • https://nvie.com/posts/a-successful-git-branching-model/

Step 3 – Now, Lets understand, what is the kind of merges we have in Git?

  • https://www.atlassian.com/git/tutorials/using-branches/git-merge
  • https://git-scm.com/docs/merge-strategies
  • https://stackoverflow.com/questions/366860/when-would-you-use-the-different-git-merge-strategies

Step 4 – Are you still having a questions, Please post in the comment section.

Tagged : / / / / / / /

How to revert the changes once its submitted in Gerrit

How to revert the changes once its submitted in Gerrit

The Revert button is available if the change has been submitted. This Reverts the change via creating a new one. When the Revert button is pressed, a panel will appear to allow the user to enter a commit message for the reverting change.

Once a revert change is created, the original author and any reviewers of the original change are added as reviewers and a message is posted to the original change linking to the revert.

However, patchsets can not be reverted. so first you have to checkout one of the previous patchset. you can get the command from Gerrit review board at each patchset download panel. After checking it out amend it to generate new commit hash then pushed again as a new patchset.

If I have multiple patch set versions for one change in Gerrit, You can only submit the latest patch set version. The design assumes that the most recent patch set is the one developers will review and test, and as such older patch sets can not be submitted.

Good Read
http://www.saros-project.org/node/155

Tagged : / / / / / /

What is a Change and Patch set in Gerrit?

Here is the short and quick description of Gerrit key teminology.

Change

Every time you push a commit with a new Change-Id Gerrit allocates a new change. Every change has a unique Change-Id and a Change Number. The change contains a number of patch sets, comments on the patch sets and a code review rating (+2, +1, 0, -1, -2). Each change has a dedicated page that shows information about it called individual change page. This includes dependencies between different changes, patch sets and the review comments.

Submit

Once a change has received a +2 in the Code Review and no negative voting in the other categories the last patchset can be submitted. This means Gerrit will now try to cherry-pick your patch set and mark the change as merged.

Patch set

If you want to modify your change, you don’t have to push a new change to Gerrit but only a new patch set . Imagine a patch sets as different versions or revisions of a change. Each patch set can receive inline comments. Gerrit uses the Change-Id of a commit message to identify patch sets of a change. This is why all patch sets of a change have the same Change-Id.

To create a new Patch when new changes are submitted
Step 1: Install commit-msg hooks for gerrit

$ scp -p -P 29418 localhost:hooks/commit-msg .git/hooks/

 

 

Step 2: Create normal commit and push (for Patchset1)

for example:

git add Server.java
git commit -m "server added"
git push origin HEAD:refs/for/master

 

 

Step 3: After doing some changes to Server.java

Finally to create new Patchset (Patchset 2)

git add Server.java
git commit --amend
git push origin HEAD:refs/for/master
Repeat step 3 for further Patches

Understanding the Patch set in Git perspective

Git is a very advanced distributed source code control system. Maintaining patch sets (often called a topic branch) in Git. Git includes a rebase capability that is very useful for a number of different operations related to maintaining a branch of code including moving a branch forward, moving a branch around on an upstream branch to look for breakage, and merging changesets to create patch files.

Git: How to create and apply patches

Creating a patch

Make your changes and commit them.
Run $ git format-patch COMMIT_REFERENCE #to convert all commits since the referenced commit (not including it) into patch files.
$ git format-patch HEAD~~

This will create 2 files, one for each commit since HEAD~~, like these:
0001-make-stuff-more-awesome.patch
0002-allow-users-to-be-locked.patch

Applying patches
You can use git apply some.patch to have the changes from the .patch file applied to your current working directory. They will be unstaged and need to be committed by you.

To apply a patch as a commit (with its commit message), use git am some.patch. \
For all patches to be applied, simply run:
$ git am *.patch

Note that in some previous version you could pass the latest patch filename of a list of patches to apply all previous patches as wel
$ git am 0002-allow-users-to-be-locked.patch # May no longer work for you

You then have the 2 unpushed commits from the patch file created earlier.

Tagged : / / / /

How to update or pull current branch before committing in Git?

Best practice says that before you commit in git, you need to either do git pull or git fetch/merge. However, there is a way to find out wheather your branches is not in sync with remote.

To check the remote repo status you are really simulating a “fetch”
$ git fetch -v –dry-run

To bring your remote refs up to date
$ git remote -v update

This command will print whether the branch you are tracking is ahead, behind or has diverged with remote. If it says nothing, the local and remote are the same.
$ git status -uno

To pull
$ git pull origin <<branchname>>
or
$ git fetch origin <<branchname>>
$ git merge remote/<<branchname>>
$ git commit

Compare the two branches:
$ git log HEAD..origin/master –oneline

Tagged : / / / / / /

Advantages of Git over SVN and perforce

What are the advantage of GIT over Subversion and perforce?

Code development has its negative and positive sides, but anything that brings more relief and gains time in a project is the developer’s best friend. CVS was for a long time the best solution for version control, adopted by all programmers in major projects. While CVS has slowly evolved into other more successful concurrent version systems like Subversion, the latest trend that manifests across the development world is the usage of DCVSs (distributed version control systems) as the main project tracking managers.

Since its launch in the mid ‘80’s and till 2000, CVS was the only real alternative as a revision control system for programmers. Not a very good one, but better than anything else. Built in 2000 by CollabNet Inc., Subversion was marketed from the start as “a better CVS” and “CVS done right.” It was truly better than CVS; unfortunately, it didn’t bring in that many new features, and under the hood, nothing has changed its core.

Because of that, there was a surge in revision control software development at the start of the 2000’s, which led to the birth and development of many DCVS projects. GNU arch and Monotone where about the first to be launched, followed by Darcs and BitKeeper.

A serious step in DVCS’ development took place after the quarrel between Linux developers and BitKeeper’s management, after BitKeeper accused one of the Linux developers of reverse engineering one of their commercially licensed features. Soon after, Linux programmers led by Linus Torvalds himself released Git as an improved open source solution to BitKeeper’s soft. Besides Git, Mercurial and Bazaar were also very successful alternatives to SVN, sharing many of Git’s features, but lagging in performance.

While SVN (Subversion) was extremely popular at the beginning, it established itself as the premiere solution in code development. Soon after, as DVCSs were developed and released, users migrated to them, abandoning SVN, opting for the more loose and faster solutions.

Nevertheless, old CVS users still tend to linger around SVN due to its familiar interface and old coding habits established over the years. Many of them question to this day Git’s efficiency in quickly putting versions together, while Git supporters, on the other hand, criticize SVN’s stiffness regarding offline work.

In many cases, the debate between Git and SVN supporters usually starts with the following features, or lack.

Git features

Offline work: Git permits any developer to branch a project and store it in a local folder as a standalone repository. After doing all the work offline, the central server or storage unit, they can than simply merge it with the central repository committing all the changes already made. This permits developers that don’t have Internet access all the time to work on a project with ease.

Central project information: Unlike SVN, which uses a .svn folder in each directory, Git uses a central .git folder in the checkout root for all project data and logs. This way, it’s easier to track changes to specific folders, on specific dates or by certain development teams. Thus, project code management is much more simplified. This also allows easy renaming of files or folders, Git automatically transmitting these changes in its history.

Easy branching: Branches and tags are much easier to create and switch in Git.

Merge history: While SVN has a branch merge history, it records all the events as coming from one user (the merger). In case a user has previously worked on a file and has not merged it, if that file is merged by another user, all the changes will be attributed to the user that merged the branch. Git, unlike SVN, can remember file changes beyond a merging point and track every user’s actions beyond project commits. Git also automatically starts the next merge at the last point it recorded.

Disk space: When the Mozilla project was ported from SVN to Mercurial (very similar to Git in performance), disk space usage went down from 12GB to 420MB, 30 times smaller than the original size. Git is supposed to use the same storage algorithms, so file size should be around the same value.

Speed: This is a no-brainer. Because all operations except for push or fetch are performed locally, Git’s speed is overwhelmingly faster than SVN could ever supply.

Better access and administration: SVN relies on an authentication module and access lists to permit users to push and merge branches. Git reduces the time spent for providing commit access to users and just lets the administration team decide what to merge and from whom.

Synchronization: It can occur over various types of media like an SSH channel, over FTP, HTTP, WebDAV, or by emails holding attached patches.

SVN features

GUI: From the beginning, SVN users have been using a GUI when managing their repository. This feature is not found at all in Git, a port for TortoiseSVN still being in the works. Besides the lack of a GUI, Git, coming from a UNIX environment, has a very complicated CLI interface with many options and arguments for its base commands.

Single major repository: Other may say this is not a good thing, but it’s a strictly SVN-specific feature. While Git allows each individual user to copy the entire repository on their computer and work on the project’s code, Subversion has always relied on permissions being given to users to only work on one single repository stored online. This feature allows the developer to always be able to download the latest version of their project without having to wait for all that work on the project to log online, upload and merge their latest branch. This is very useful in fast development environments or application troubleshooting.

Partial checkouts: Git doesn’t offer the possibility to download only a single folder from the repository. This may be a disadvantage to developers not having great bandwidth or speed.

Version numbers: Another keeper from the UNIX fathers of Git is the complicated version control numbers. While SVN uses a simple incremented decimal system, Git employs an SHA1 algorithm to output a 40-character hexadecimal string as the version number. This could get very tiring when having hundreds or more versions.

The abovementioned features are only a scratch on the surface when discussing about the version control system war between CVS/SVN supporters and DVCS users. More on the topic can be read here, which puts all the major platforms’ features next to one another so they can be compared.

Let’s now take a look at the parties involved and analyze their impact on the current programming and development world.

Subversion, as of 2009, was recently included in the Apache Incubator project, mainly because of its long usage history in most of the Apache Foundation’s projects. More details are available in one of my past articles on this topic. Other famous open source or commercial projects that have a weakness for SVN include market players like Ruby, Mono, Free Pascal, ExtJS, Tigris, PHP, MediaWiki, GCC, Django and FreeBSD. All having their source code administrated from an SVN repository.

On the other hand, the community’s favorite project, Git, is currently expanding its horizon every day, recently taking GNOME and The Perl Foundation away from SVN, placing them alongside other notable Git-powered projects like Android, Linux, openSUSE, Yahoo User Interface, x264, Digg, jQuery, X.org, Samba, Ruby on Rails, CakePHP, Fedora, Merb, Freenet, GIMP, Parrot, Qt, rsync, Wine and VLC.

Other Git-like products like Mercurial (originally designed to replace BitKeeper for Linux development) have also been adopted by major corporations and programs like Mozilla, OpenJDK, OpenSolaris, Netbeans, OpenOffice, Vim, SAGE, Growl, Wget, Symbian OS and Adblock Plus. In 2010, The Python Foundation is going to join this list, migrating from SVN.

Another Git-like DVCS platform, generally regarded by the community as being slower than Git, but much easier to learn is Bazaar. This is a product developed especially for Ubuntu, but which saw adoption in many other projects around the web, some of them like Squid, APT, MySQL, GNU Emacs, Gnash and Inkscape.

The trend is easy to see. DVCSs are adopted in more and more projects, while SVN is headed for the history books alongside its precursor, CVS. The final battle in this version control systems war is being waged on the grounds of project storing platforms the likes of SourceForge, Google Code or CodePlex. The winner of this confrontation will surely decide whether SVN will be used in the coming future or whether it will fade away from our minds like the early PC consoles.

Currently, SourceForge and GNU Savannah have the biggest and widest hosting platforms, providing version control platforms like CVS, SVN, Git, Bazaar and Mercurial to all of their users free of charge. For SourceForge, by default, a project will be hosted on Subversion. The same happens in Google Code, where SVN is the default, but the Mountain View-based crew also provides Mercurial as a DVCS alternative. Renowned hosting platform, CodePlex, provides SVN, Mercurial and Microsoft TFS hosting, while the smaller service on Project Kenai offers SVN, Git and Mercurial.

Also lately, due to high technical costs, services are starting to opt only for one version control system, putting some heat in the discussions between the CVS communities. The list is as follows: Mercurial has exclusivity on Bitbucket, Bazaar on Launchpad; Git on Github, Codaset and Gitorious, and SVN on BountySource, Freepository, GridyZone and Origo. A slim crop for SVN, but being the default service on Google Code and SourceForge might give it a fighting chance against the up-and-coming Github.

Some of you might not agree with the previous claim that this is a “battle” and should not be at all compared with the browser wars, but the community deeply rooted in the tech world already knows this is more of a fact than a myth. As proof of concept, we bring you this video from a conference at Google back in 2007, where Linus Torvalds, the inventor of Linux and Git, made some outrageous statements regarding SVN, and especially its users.

If you don’t have the time to view this one-hour long video, we’ve listened to the conference and taken some interesting quotes from Mr. Torvalds: “Subversion has been the most pointless project ever started,” continuing with “Subversion used to say CVS done right: with that slogan there is nowhere you can go. There is no way to do CVS right” and ending with “If you like using CVS, you should be in some kind of mental institution or somewhere else.”

Not very heart-warming comments from a public person like Linus Torvalds. Especially being made in the headquarters of one of the companies that have ignored Git and failed to include it in the Google Code project. Nevertheless, Mr. Torvalds might also be under the influence of an inner demon, specific to most UNIX users to prove that any project developed and coming from a Linux environment is better than anything else.

True or not, Git has seen a rise in usage, as proved by the 2008 and 2009 Kernel.org surveys, which had it ranked above any other versioning control platform like SVN, Bazaar and Mercurial, and with a crushing 94.6% rate of overall satisfaction toward the Git user experience. As a conclusion, it is generally acknowledged that future versions of Git will be adopted in more and more environments, and Git will have to fight only against other DVCSs for supremacy in the programming world.

One more good link for Advantahe of git over SVN(Subversion) …

http://markmcb.com/2008/10/18/3-reasons-to-switch-to-git-from-subversion/

Tagged : / / / / / / / / /

Git Polling Log java.io.IOException: error=2, No such file or director

rajeshkumar created the topic: Git Polling Log java.io.IOException: error=2, No such file or director
Error
Started on Sep 15, 2015 9:57:00 AM
Using strategy: Default
[poll] Last Built Revision: Revision 2c06c1d705f61e2654d7f30131d8205d6b755d09 (refs/remotes/origin/master)
> /mnt/jenkins/git/2.3.1/bin/git –version # timeout=10
> /mnt/jenkins/git/2.3.1/bin/git ls-remote -h server.com/repo-provisioning.git master # timeout=10
FATAL: hudson.plugins.git.GitException: Error performing command: /mnt/jenkins/git/2.3.1/bin/git ls-remote -h replica.int.devsnc.com/devsnc-provisioning.git master
hudson.util.IOException2: hudson.plugins.git.GitException: Error performing command: /mnt/jenkins/git/2.3.1/bin/git ls-remote -h http://server/repo-provisioning.git master
at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:527)
at hudson.scm.SCM.compareRemoteRevisionWith(SCM.java:384)
at hudson.scm.SCM.poll(SCM.java:401)
at hudson.model.AbstractProject._poll(AbstractProject.java:1433)
at hudson.model.AbstractProject.poll(AbstractProject.java:1336)
at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:515)
at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:544)
at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Caused by: hudson.plugins.git.GitException: Error performing command: /mnt/jenkins/git/2.3.1/bin/git ls-remote -h http://server/repo-provisioning.git master
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1464)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1245)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1143)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1134)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getHeadRev(CliGitAPIImpl.java:2139)
at hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:576)
at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:525)
… 13 more
Caused by: java.io.IOException: Cannot run program “/mnt/jenkins/git/2.3.1/bin/git”: java.io.IOException: error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:470)
at hudson.Proc$LocalProc.(Proc.java:244)
at hudson.Proc$LocalProc.(Proc.java:216)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:803)
at hudson.Launcher$ProcStarter.start(Launcher.java:381)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1453)
… 19 more
Caused by: java.io.IOException: java.io.IOException: error=2, No such file or directory
at java.lang.UNIXProcess.(UNIXProcess.java:148)
at java.lang.ProcessImpl.start(ProcessImpl.java:65)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:452)
… 24 more
Done. Took 21 ms
No changes

Solution –
A work around of adding the “Force polling using workspace” as an “Additional behaviour” in your git SCM definition of the windows job.
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

Tagged :

Git Polling Log java.io.IOException: error=2, No such file or director

rajeshkumar created the topic: Git Polling Log java.io.IOException: error=2, No such file or director
Error
Started on Sep 15, 2015 9:57:00 AM
Using strategy: Default
[poll] Last Built Revision: Revision 2c06c1d705f61e2654d7f30131d8205d6b755d09 (refs/remotes/origin/master)
> /mnt/jenkins/git/2.3.1/bin/git –version # timeout=10
> /mnt/jenkins/git/2.3.1/bin/git ls-remote -h server.com/repo-provisioning.git master # timeout=10
FATAL: hudson.plugins.git.GitException: Error performing command: /mnt/jenkins/git/2.3.1/bin/git ls-remote -h replica.int.devsnc.com/devsnc-provisioning.git master
hudson.util.IOException2: hudson.plugins.git.GitException: Error performing command: /mnt/jenkins/git/2.3.1/bin/git ls-remote -h http://server/repo-provisioning.git master
at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:527)
at hudson.scm.SCM.compareRemoteRevisionWith(SCM.java:384)
at hudson.scm.SCM.poll(SCM.java:401)
at hudson.model.AbstractProject._poll(AbstractProject.java:1433)
at hudson.model.AbstractProject.poll(AbstractProject.java:1336)
at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:515)
at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:544)
at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Caused by: hudson.plugins.git.GitException: Error performing command: /mnt/jenkins/git/2.3.1/bin/git ls-remote -h http://server/repo-provisioning.git master
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1464)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1245)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1143)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1134)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getHeadRev(CliGitAPIImpl.java:2139)
at hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:576)
at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:525)
… 13 more
Caused by: java.io.IOException: Cannot run program “/mnt/jenkins/git/2.3.1/bin/git”: java.io.IOException: error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:470)
at hudson.Proc$LocalProc.(Proc.java:244)
at hudson.Proc$LocalProc.(Proc.java:216)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:803)
at hudson.Launcher$ProcStarter.start(Launcher.java:381)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1453)
… 19 more
Caused by: java.io.IOException: java.io.IOException: error=2, No such file or directory
at java.lang.UNIXProcess.(UNIXProcess.java:148)
at java.lang.ProcessImpl.start(ProcessImpl.java:65)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:452)
… 24 more
Done. Took 21 ms
No changes

Solution –
A work around of adding the “Force polling using workspace” as an “Additional behaviour” in your git SCM definition of the windows job.
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

Tagged :

Good GIT SCM Video at youtube.

rajeshkumar created the topic: Good GIT SCM Video at youtube.
Hi Friends,

This week I am started digging more into to GIT. I hope these videos will be helpful for you as well.

Introduction to Git

Linus Torvalds on git

O’Reilly Webcast: Git in One Hour

Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

Tagged :