The Naughtiest way to Understand Version Control System (of course Git )!

I thought Git was a jailer watching my every move. It turns out, Git is my worker-man, and we’re out here taking snapshots.

How I arrived on the above line ! Its down Here ?

I thought a version control system was something that saves and tracks a linear timeline of events where you move between undo and redo states, but I got to know that it doesn’t actually work like that and evolved into this:

“VCS is a system that saves work as snapshots.”

I have evolved after tinkering with some questions to reach that stage. I will say why in a bit;

so, let me take you inside my mind! 😃 Help yourself.

First, let me choose a version control system. After a minute of thinking, I choose what? Any guesses? Tadaa! Git

When a VCS like Git is initialized using git init and running git status shows this:

On branch main

No commits yet

Untracked files:

(use "git add ..." to include in what will be committed)

client.js

server.js

tcpserver.c

nothing added to commit but untracked files present (use "git add" to track)`

Now this says (VCS) that there are untracked files. Mm-hmm! I gave it a thought (a peek inside my-mind now note: this was made in my naivety period).

A VCS is like a jail that would completely stop my exploration and whatever I did is being noted.

Only later did I realize that it isn’t like that (of-course I arrived at this stage after an long-enquiry with a LLM about a file being untracked)— it’s my worker-man. That is, from my untracked files, I can choose only what I need, send that to the staged (tracked) area, and then, if everything is okay, I commit it. If not, I can bring it back to the untracked stage, work on it again, stage it, and then commit

And now, on the Git-managed project, I thought:

“Okay, I will add these files into tracking mode after doing some thinking, writing code, and reaching a stage that’s minimally working and in an observable state.”

hen my genius-explorer kicked in, and I thought,

“If changing state from untracked to tracked meant after I have set the file as tracked, can I modify something in the tracked file, go back to the previous state on the file, then come back to the present, like undo/redo in a text editor? And can this undo/redo stay untracked before it is ready?”

So, let me do this on a VCS Git to observe what happens!

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   client.js
        new file:   server.js
        new file:   tcpserver.c

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   server.js

After this little manual-work , I understood from an LLM (not Gemini by the way 😀):

That there are only untracked, staged/unstaged, and committed states. From the axiom ‘that VCS is a system that stores works as snapshots,’ let me translate the message for you:

Now what the Git VCS system says is, “These are the files which are in the stagedstate and are going to be sent for a snapshot, but I found among those that one file is modified: do you want the staged one or the modified one to be ingested into the snapshot? Which one do you need, buddy??”

After this, I can say to the VCS which file-version is to be ingested for snapshot ; Once snapshot is done it immutable can be deleted but not modified

now A little axiom on Untracked and Un-staged are different:

• Tracked + Unstaged: Git knows the file exists but isn’t planning to save the new changes yet (which is to ingest them into the snapshot that is going to be created).
• Untracked: Git doesn’t even know the file is part of the project.

So, now I have built a workflow in my mind which works for me using the evolved axiom;

Consider I am building a software application. There is this big software component. Now, to add new features, let me walk you through my workflow.

1. Doing whatever the fck I want, to get a better understanding of the available arsenals and possibilities to build (on personal projects, limited exploration on professional ones if limited time is provided).
2. Then, making it an observable state.
3. Personal review, a little tinkering, and anticipating failures and having a re-iteration on design and code levels.
4. Is the feature requirement satisfied with long-term maintainability? (PS: I know, seniors, this should be done in the initial stage before writing code; I will adapt and I promise I will follow this.)
5. If yes, now linting and resource-level check of how this will work on resources.
6. Then Stage → then Commit; now this commit enters into the software component as a whole.
7. So now there, I can have gatekeepers who can verify this and make a decision that this work can be allowed in the whole software component.

This can be scaled up to branches on a Version Control System before arriving at the optimal ones.

And this was quite an adventure and gave me a perspective that

“whenever I am going to do a commit operation on a version control system, that I am making an immutable snapshot, which is a saved state of work, and the freedom to try and iterate to the best solution.”

Cheers🥂 Until Next Time !!!!