Version Control with Git — 1
In the realm of version control and collaborative development, Git stands as a cornerstone. Its threefold structure — working directory, staging index, and repository — orchestrates seamless file management. Commits, repositories, and SHA identifiers synergize to encapsulate project evolution, while branches empower agile development.
Imagine we have a repository comprised of three distinct files-an html, a javascript and a css. Our intention is to introduce version control into this project. So, we initiate a new Git repository.
Within a Git repository, there are three fundamental areas: 1. the working directory, 2. the staging index, and 3. the repository proper.
These segments represent the core divisions within Git’s structure. The alterations to the local files don’t manifest visibly, but Git diligently orchestrates these distinct areas, with the Git shell commands serving as our means to orchestrate file movement between these segments.
Inititally, the repository is empty.
New files (in the working directory) is labeled green. Git’s registry logs these files, and captures their existence. But these files can’t be directly incorporated into the repository.
They must first traverse through the staging index. Hence, the Git commands allow us to facilitate the relocation of these changes to the staging index — an intermediate zone where files are prepped for commitment.
Subsequent to staging, we proceed to commit these changes, effectively integrating them into the repository.
<new/changed_file> — — Staging — -Commit.
In the event that we introduce modifications to the CSS file associated with our site, Git promptly detects these alterations and annotates the file as “modified.”
Echoing the prior steps, the workflow remains consistent: we migrate the CSS file changes to the staging index and subsequently initiate a commit.
