As previously noted, GitHub provides a remote VCS that we can use to mirror the VCS environment we maintain locally through Git. On larger projects, GitHub can serve as a centralized VCS providing team members with a single location serving a codebase that is stable and yet also representative of the unified state all team members have contributed to. We will examine Centralized Workflow at a later stage.
Git refers to our projects as being in one of three different States, Modified/Edited, Staged, or Committed.
So how do we work with VCS, on our own software development projects?
- Firstly you will need to download and install Git.
- Then you must register a remote VCS account such as with GitHub.
- You will then create a folder, which will be your working directory and serve as the root location for your project.
- You will then need to initialize your VCS project. These steps will be explained in greater detail.
Initially, when we start a project it is said to be in the Modified state. Continuing to work on the codebase does not change its Git-related state i.e. the software remains in the Modified State.
In order for Git to track changes to the project and provide us with the functionality that allows us to revert to previous versions of the project we need to stage the code in the modified state and then commit the changes. This is simply a directive (or command) issued to Git to tell it to track and store the current status of the project. Once we have committed the changes locally we can then push these changes to the remote repository which will subsequently mirror the local project, at this stage. Before making a commit we need to tell Git which files we would like to add to the commit. Files that are added to the queue to be committed, will be analyzed for changes and placed in the Staging Area. Let’s have a look at a practical example of how we would stage and commit a modified codebase.