This blog is written with an intention to act as a transition guide for existing users of CMVC ( or similar SCM tools ) to start using Git.
For folks who are new to either CMVC or Git; both are Source Code Management(SCM) tools like CVS, SVN(Subversion) and Clearcase. If you have been into software programming, there is a very good chance you would have used one of these ( or other similar SCM tools ).
There are very good reasons on why you should consider using Git as your SCM and there are multiple articles out there in the “Internet (www.google.com ?)” which already give out the details. In short, unlike the earlier generation client-server model SCMs; Git was designed to be distributed in nature.
This blog is not intended to teach Git or help getting started with it. It is intended for audience who have already grasped the basics of Git; but are unsure on how to relate the existing activities on other SCMs (like CMVC) to Git philosophy.
If you have not yet done a “Git 101” kind of a course, i suggest you to do that first.
You could use one of these links; or search in Google to get the learning resource which suits your taste :
  1. http://assets.en.oreilly.com/1/event/45/Git%20101%20Tutorial%20Presentation.pdf
  2. https://git-scm.com/book/en/v2
  3. https://www.atlassian.com/git/tutorials

Is there a centralized server as source code repository in Git ?

Git provides all of the well renowned logic to ease out source code version controlling; but you still need a place( read storage ) where you could place all of your code “safely”. Although you could use your local computer as the repository, obviously it is the least safe place! Apart from that, you need a place where other members/collaborators could “share/contribute” to the same project.
For that you need to use a source code hosting facility provided by the likes of GitHub, GitLab, Bitbucket, Launchpad etc.
This wikipedia page has a very comprehensive list of such hosting facilities : https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities.
The popular of the lot (at the time of writing this blog) is GitHub, and i’ll refer to some of the terms used in GitHub wherever required for the rest of this post.
To get familiar with GitHub you could get started here : https://guides.github.com/activities/hello-world/

Can an entire project life-cycle be managed with GitHub ?

With GitHub alone, it might not be easy to manage a project. but there is this useful add-on called ZenHub.
ZenHub provides useful extensions on top of GitHub for better management of projects. One of the popular choices for “Agile project management with GitHub” ( as ZenHub claims ) !

How do i relate my work in CMVC(or other similar SCMs) to this new way of working with Git?

Let’s start with a one-to-one mapping between the commands/philosophy in CMVC and map that to “Git / GitHub / ZenHub” put together.
Repository
A repository contains all of the code ( and documentation etc. ) required for a project. Just like you would have used a centralized server for CMVC; you could consider GitHub as the alternative here. Though, Git has the ability to make a directory in your local computer as a self-sufficient, full-fledged source code repository; that would be a risk for bigger projects. Also, you’ll not get the other project management facilities you get with “GitHub + ZenHub“.
Defect
A “Defect” of CMVC is known as an “Issue” in GitHub parlance.
Once you are in a “repository” view of GitHub you’ll see multiple tabs and the 2nd one being “Issues”
Just like a CMVC defect_number, GitHub assigns a number for issues. You can assign and work on an issue similar to a defect.
Use the #<issueID> while adding message ( e.g. “Fix #10” ) to your git file commits and then the commits automatically gets associated with the particular issue ( e.g. #10 ).
Feature
With ZenHub extension to GitHub you can create an “Epic” which is more like a “Feature” of CMVC.
In Agile terminology, an Epic is a large piece of work, which could be broken down into user stories.
And here each user story can be tracked as an “Issue”.
Working on a Defect ( aka Issue )
Let’s say that you are going to start work on a project for which a repository is already created in GitHub ( i.e. with all the existing source code “or” maybe a new empty repository ).
  • First thing you need to do is, “clone”(git clone) the repository locally and if you don’t specify a branch, the “master” branch gets cloned.
  • In most cases it might be sufficient for you to have this single local copy (aka clone) for most of your work. ( This is similar to a “File -extract” of the entire code-based in CMVC ).
  • Then you “create a branch” ( git branch, aka context ) with an appropriate name maybe including the issue# you are working on e.g. issue_123. You could though give any name to the branch.
  • Then you need to “checkout” ( git checkout ) that branch (i.e. you move to the context of that branch).
You could find it amusing initially on why there are 2 steps ( clone + branch ) to start working on a branch(defect/issue); but you’ll realize the need when you find out that Git provides the flexibility for you to work on multiple branches(read issues) from a single code copy/location.
You could do some partial work on a branch and move to a new branch for some other work ( e.g. a separate defect ); just by changing the context ( aka checking out a new branch ). And come back to the earlier defect by switching back to the earlier context (branch).
File operations
  • Always check the context(branch) before starting to make changes to a file. If you are not in the right branch, checkout the required branch first.
  • Once inside the appropriate branch, modify the files as required; by directly editing them. ( nothing like “File -checkout” of CMVC required ).
  • When you are done with all the changes, commit ( i.e. “git add  and then git commit ) the changes to the branch. This is similar to “File -checkin” in CMVC. Remember all of this is happening on your local computers repository. When you are done with all of your changes; you need to push ( git push ) the locally created/committed branch to the remote server( aka origin in GitHub terms ).
  • Once your branch is pushed to the remote GitHub repository( aka origin) you could raise a review request by creating a “pull request” in GitHub.
  • At this stage, the marked reviewers would be able to review your changes.
  • You could address the review comments by making the changes in the same branch and then redo : git add, git commit, git push.
  • Once the reviewers are satisfied with your changes, you( or repository owner ) will “merge” your changes to the higher level branch or master ( read more here for one preferred method : https://guides.github.com/introduction/flow/ ).
Note : 
  1. In Git there is no explicit “File -checkout” required before editing a file; as each contributor could be editing the same file at the same time. There is no explicit “write lock” placed on the file as is the case with CMVC. This i see as complementary to the flexibility ( distributed work ) of Git.
  2. Unlike CMVC and other traditional version control systems which are centralized, Git is a distributed revision control system. What it means is that you can do work from your local copy of the repository even when you are not connected to the network.

Wow, i am overwhelmed, what next ?

Start using Git; then go back and revise some of the other training articles which you referred earlier to get started with Git ( maybe go to the advanced sections then ). I am recommending a revision because there are many other “useful” features in Git + GitHub + ZenHub; which you will only appreciate later; only after you are comfortable with the basics.
If you have any questions specific to this article, i’ll be happy to help in the comments section.
 

What do you think ?

Set your Twitter account name in your settings to use the TwitterBar Section.
%d bloggers like this: