<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Why Version Control Exists]]></title><description><![CDATA[Why Version Control Exists]]></description><link>https://vcsnand.hashnode.dev</link><generator>RSS for Node</generator><lastBuildDate>Thu, 17 Sep 2026 03:58:44 GMT</lastBuildDate><atom:link href="https://vcsnand.hashnode.dev/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[Git basic and essential commands]]></title><description><![CDATA[→ Git is a tracker or version control system which tracks different versions of the same file.
Git is used to see the ultimate truth for a code on which the whole team can rely upon. Git lets us see who changed the code, when it was changed, what was...]]></description><link>https://vcsnand.hashnode.dev/git-basic-and-essential-commands</link><guid isPermaLink="true">https://vcsnand.hashnode.dev/git-basic-and-essential-commands</guid><category><![CDATA[Gitcommands]]></category><dc:creator><![CDATA[Nand Kishore]]></dc:creator><pubDate>Fri, 16 Jan 2026 17:53:23 GMT</pubDate><content:encoded><![CDATA[<p>→ Git is a tracker or version control system which tracks different versions of the same file.</p>
<p>Git is used to see the ultimate truth for a code on which the whole team can rely upon. Git lets us see who changed the code, when it was changed, what was changed and even if the code has a bug, it can be reverted back to the cleaner version of the code. It makes collaboration easy and prevents the code from getting messy.</p>
<p>→ Key terminologies:</p>
<ol>
<li><p>Staging area → stage refers to ki jidhar performance hone wala ho. To jo bhi stage pr aayga wo commit yani ki save hone ke liye ready ho jayga. Basically maine file ko track krna shuru kr diya hai.</p>
</li>
<li><p>commited area → Whatever was in the staging area are shifted to commited area where the file actually gets saved.</p>
</li>
<li><p>head → The latest commit is called head. Each commit stores the reference of its previous commit like a linked list.</p>
</li>
</ol>
<p>→ Git commands</p>
<ol>
<li><p>git init → It simply tells the folder now youre been initialized. You are going to be tracked in future. It makes the .git/ folder which will track the code.</p>
</li>
<li><p>git add &lt;filename&gt; → It adds the file into the staging area. This code is finally getting started to be tracked.</p>
<p> If “git add .” is used then it will add files in the folder to the staging area.</p>
</li>
<li><p>git status → It simply tells the user that which part of the code is changed in the main file which is not yet sent to the staging area. It just reminds that which part of the code will get commited.</p>
</li>
<li><p>git commit -m “&lt;Message&gt;“ → Whatever is in the staging area will get commited with the message written. This message usually tells that the commit does a particular job. Also, each commit gets an id.</p>
</li>
<li><p>git diff → Between two files, it tells what is the difference between these two files determined by their id.</p>
</li>
<li><p>git log → GIves detailed commit history. git log —oneline gives one line history of commits.</p>
</li>
<li><p>git revert &lt;id&gt; → it adds the code which was removed from that id wala code and removes what was added in the code. It basically was complemet. and is added as a new commit.</p>
</li>
<li><p>git reset —hard &lt;id&gt; → It shifts the head to the id here and thus the refernce to other ids after them gets lost. Thus unaccesible and this thing cant be done back. So better to use revert one.</p>
</li>
</ol>
]]></content:encoded></item><item><title><![CDATA[Why VCS exists : The pendrive problem]]></title><description><![CDATA[The problem arises when two or more developers are working on a single project. It is kind of ok for a single developer. For a single developer let’s say Ram writes a code and saves it. The only problem with single developer is that they can’t track ...]]></description><link>https://vcsnand.hashnode.dev/why-vcs-exists-the-pendrive-problem</link><guid isPermaLink="true">https://vcsnand.hashnode.dev/why-vcs-exists-the-pendrive-problem</guid><category><![CDATA[#cohortvcs]]></category><category><![CDATA[version control systems]]></category><category><![CDATA[version control]]></category><dc:creator><![CDATA[Nand Kishore]]></dc:creator><pubDate>Thu, 15 Jan 2026 03:35:37 GMT</pubDate><content:encoded><![CDATA[<p>The problem arises when two or more developers are working on a single project. It is kind of ok for a single developer. For a single developer let’s say Ram writes a code and saves it. The only problem with single developer is that they can’t track the code that when they changed the code.</p>
<p>Later, he found that there was a bug in the code and asks his teammate Shyam to patch it. Ram saves it in a pendrive and gives the pendrive to Shyam. Shyam adds a lot of code and returns the pendrive. The first problem arises : There is no track of which part of the code was added. If there would have been that who added the code and when, this issue would have resolved.</p>
<p>Another problem : if both Ram and Shyam writes different code in the same project then code would be conflicted and then they are no longer working on the same project. And the code would get messy. So, to fix it, we will track who wrote the messy code and revert it back. Its also a nice tool for blaming the person who wrote messy code.</p>
<p>The ultimate source of truth should be made. Noone will ask that what code you have written or so. The pendrive here was the source of truth on which everyone relied upon. And for everyone to collab, we need a server, a platform.</p>
<p>In total, the pendrive problem is that you wont be able to track, basically who changed the code, when it was changed and what was changed.</p>
]]></content:encoded></item></channel></rss>