Ready, Set, GIT!
Part IV — Check Git Out!
This article covers the ongoing maintenance of a Git repository from the perspective of the pull, commit, and push command sequence. I will address how we then perform these actions so that our repository stays in sync and maximizes the recoverability of our precious code base.
Going forward as we explore coding in Unity (or any other development environment that uses Git as a repository), we will want to develop a sequence of repeatable steps that will ensure the ongoing integrity of our repository.
The basic command sequence that will ensure consistent usage of Git is: Pull, Add, Commit, Push. I will explain each of these commands in depth in the rest of this article.
PULL
The Git “pull” command grabs and loads the most recent version of the repository from the central GitHub site. By performing this action first, we can be assured that any and all of our pending changes will merge with the current codebase correctly.
More precisely, the Git “pull” command is actually a combination of two other commands, git fetch followed by git merge . In the first stage of operation Git “pull” will execute a git fetch scoped to the local branch that HEAD is pointed at. Once the content is downloaded, the Git “pull” will enter a merge state and incorporate all changes from the central repository into the local repository.
The basic format of the “pull” command looks like this:
git pull origin main (or master instead of main if you are using the old nomenclature of the git commands)
ADD
The Git “add” command allows us to add new content to our codebase. It identifies all new “unmarked” files and folders since the last commit. It does that by adding them to the “index” of the current working set of files and folders. The “index” is essentially a “snapshot” of the codebase as of the last commit to the repository.
The command syntax shown above will add ALL files and folders not already included in the index of the repository.
The command syntax shown above will all all MS Word documents from the “Specs” directory (including all sub-folders under “Specs”).
COMMIT
The Git “commit” command more or less puts your stake in the ground as if to say, “What I have here is good to go”. You will provide a message stating what the content of the pending changes you are making include. There are entire guides for how to write a structured, consistent, and useful commit message. I do not intend to cover them here.
NOTE#1: Here is a very important difference if you are used to using a repository product other than Git. Using the “git commit” command only saves a new commit object in the local Git repository. On the other hand, the Subversion repository system writes its commit to the remote server where the central repository is located, thus REQUIRING a direct connection with the source.
NOTE#2: On the original commit, Git may want you to verify your account’s default identity. If so, enter the following command.
PUSH
The Git “push” command does the final move of the new and modified files and folders into the remote repository indicated by the link it has for the “origin”. It timestamps each one with the commit information that was provided. It also groups those changes as a package that can be moved or removed at a later point in time if necessary.
In addition, when you “push” the new/modified files back to the repository, the command gives you the option to select the specific “branch” that you want to use to push your changes. I will be covering that in the next article.
For now, just use the following command syntax to get your changes into your remote Git repository.
Finally, we move to “Part V — Going Our Separate Ways” in the final article of this series on Git. This article covers Git Repository branching. Branching addresses the concept of non-destructive modifications to our code. It is probably the most important aspect of why we use Git for repository management.
