Program-Independent > Programming
Git Basics
Contributors:
Hamid Hussain
Hamid Hussain
Git is the most popular source control software for developers, and allows for robot code to be worked on by multiple people and hosted in the cloud.
In order to develop competition robot code for FTC and FRC, you must understand the basics of how to interact with Git and our chosen cloud provider, GitHub.
A Git Repository, sometimes referred to as a Repo, is a collection of folders and (usually text) files that appear like any other folder on your computer. The only difference is that repositories are managed by Git, and allow you to access its collaboration and version control features for the repository's contents. We store code for FTC and FRC robots in repositories, and there is (usually) one repository per robot/project, which contains all of the code files that it needs.
A remote repository is a repository that is hosted on a remote server, such as those of popular service GitHub. These remotes are used to upload code so that multiple people can download them and publish changes. In comparison, a local repository is a repository stored on your local computer. If you clone a remote repo from a server, your copy of the repo is a local repository. Cloning, in this case, is creating a linked local copy of a remote repo.
The repository for FTC Green Team's 24-25 season robot, as displayed on GitHub.
A commit is an action that is done to a local repository to update it with any changes that you have made to the files in the folder, also known as the "workspace" or "working copy". A commit tracks the changes you made since your last commit, including file additions, deletions, and modifications, and it is necessary to commit your changes to the local repository before you push them to a remote.
Commits are at the heart of Git's source control/version control feature, as each commit acts as a new version of the repository with the new changes made between the current and previous commit. Each commit has a description (or message) that you write to describe the changes.
Previously, I described the act of taking code from a remote repository as "downloading" and the act of putting code into a remote repo as "uploading". However, in Git terms, these two terms are replaced with Pulling and Pushing respectively. When you pull a repository, you are updating an existing local repo with the newest changes that exist at the remote. Fetching is similar to pulling, except it does not interfere with your working copy. Conversely, when you push code, you either upload a local repo's worth of code to a remote repository, or update an existing remote with new changes.
Every repository has one main/master branch by default, which contains all of the commits. If you want, you can take a commit and branch off of it, basically choosing to add changes to that commit separate from any other work being done. This is useful if you have a large team and want different people to work on separate features. Git Branches are often shown through a diagram such as the one here, where the different lines represent different branches, and the dots represent commits. After you are done with the changes on a branch, you can combine, or merge the changes with the branch you originally branched off from (usually the main branch).
Merging usually happens when combining different branches or pushing to a remote. It is the process by which multiple changes are combined to form a single tree of files and folders. Most of the time, this process is done automatically, but sometimes, when many changes affect the same file or part of a file, the merge cannot complete automatically and encounters a merge conflict. In this case, the conflict has to be manually resolved, usually by picking between two versions of the code to save in a Git-enabled IDE (programming software).
The following image shows a merge conflict in the Visual Studio Code text editor. The branch "his-branch" is being merged to the branch "my-branch" at the latest commit. However, one branch has the sequence "red, green, blue" while the other has "red, white, blue". The software is prompting the user to pick between green and white before merging.
In order to make use of Git's features, we must install it to the device that you will be programming on.
On Windows, Git can be installed using the Git For Windows installer, which installs the Git Bash and Git GUI. The Git Bash will be used to run all commands seen later in the article. Navigate to the website using the button and click download, then run the EXE file to install.
Installation instructions for MacOS and Linux can be found on Git-SCM. Simply follow the instructions for your operating system/distro. Many Linux distributions already come with Git pre-installed, and you can check if you have it by running the git command in the terminal without any other keywords.
DISCLAIMER: The syntax of these commands have been simplified.
The clone command is used to clone a remote repository, which creates a linked copy of it on your local computer. Often, you want to use this to start editing an existing remote repo.
Syntax
git clone [URL]
In the case of GitHub, the repository's URL can be found using the large "Code" button on it's front page.
Examples
git clone https://github.com/NicholsSchool/2025-Mokey.git
After running the clone command, a new folder will be created inside whichever directory you run the command from, and all further commands related to that local repo should be run from inside of it. The folder will share the name of the repo by default, but you can rename it.
The remote command is used for managing the remote repositories that your local repo is linked to. By default, a local repo will either have no remotes if it was created locally, or one remote - "origin" - if it was cloned from a remote. Using the remote command, you can unlink and relink a local repo to any remote.
Syntax
git remote [add/remove] [name] <URL>
The first argument for the command simply tells git whether you want to add or remove the specified remote. The name of the remote is either used to select an existing remote (for removal) or to name a new remote (when adding). The URL is only used when adding, to specify which remote repository to link the local repo to.
The commit command is used to commit changes from a working copy to a local repository.
Syntax
git commit <-a> -m [commit message]
The commit message should provide a short description of the changes made. The "-a" flag of the commit command is used to commit changes from all files that have been modified since the last commit. If you do not use the -a flag, you must use the add command beforehand to specify which files to include in the commit.
The add command is used to stage specific files before a commit, if you do not want to commit changes to all files.
Syntax
git add [filepath]
Examples
git add .
Stages all changes in the repositorygit add /src/*.java
Stages changes to any java file in the repo's "src" folderThe push command is used to push local commits to a remote repo. Usually, we only use one syntax for the push command, which simply adds your commits to the top of the branch you are editing.
Syntax
git push origin HEAD
Here, origin is the remote that is being pushed to. If you set a different name for the remote, then substitute origin for that name. HEAD simply means the top of the current branch, and it means you don't have to type out the whole branch name.
The pull and fetch commands can be run with no further arguments and simply pull changes from the remote into your local repo with or without changing the contents of your working copy.
The switch command can be used to change which branch of a repository you are editing. It replaces the older checkout command and is much simpler.
Syntax
git switch [branch name]
The branch name should be the name of the branch you would like to switch to.