This post series is indexed at NgateSystems.com. You'll find a super-useful keyword search facility there too.
Last reviewed: Dec '24
1. Introduction
Post 1.1 mentioned VSCode's "timeline" facility as a means of tracking the changes that you have made to your files. Microsoft's Git "repository" system is a timeline on steroids!
Locally, Git provides a "repository" mechanism to wrap a project's files up in a framework that tracks their changes. Thus far, then, it's not significantly different to a VSCode Timeline. But things get more interesting when I tell you that Git enables you to use a "commit" arrangement to sign off a whole collection of file changes as a "recovery" point for your project. In the event that things go badly wrong subsequently, you can then use Git commands to roll back the whole project to such a recovery point.
Additionally, Git enables you to use a "push" command to create a copy of your local project at a commit point onto a master copy on the web. Typically, you would use this to create a secure backup "recovery" copy of your code when you deploy a new version of your webapp.
If you want to streamline your operation, Git automation enables you to automatically trigger a deployment when you make a Git push.
As a beginner working alone, this might be all you need to know about Git. But you'll find things getting even more interesting if you collaborate with others on a common body of code.
In this situation, each team member typically works on their own local copy of the master Git repository. When a team member decides to merge their changes into the master remote version of the repository, they make a "push request."
This invites the repository owner to review the proposed changes and negotiate with the developer over any necessary adjustments. When a push request is finally accepted, the associated changes are merged with the master repository, and it now becomes necessary for other developers to bring their local repositories up to date. They now receive "pull requests" and may have to make consequential changes to their own local code before merging these into their own local repositories.
A description of these "team" arrangements is well outside the scope of this post, but you
Top comments (0)