Copia Automation delivers modern developer tools for industrial automation. Our Git-based source control solution for PLCs streamlines workflows for faster delivery and maximized uptime.
Despite being used by millions, Git can be difficult to learn. We at Copia find that many people struggle more with the terminology than the actual Git-based processes. To help smooth this learning curve, we have created this Git Glossary, which can be referred to when learning Copia Automation.
Git is a modern VCS (version control system) that works with a wide range of operating systems and IDEs (integrated development environments). Git is an open-source project that was founded in 2005. It is used by software teams and developers globally.
Git uses repositories to store each version of an individual developer’s code. It offers features including merging, reverting, and branching, allowing developers to work on different parts of the same code simultaneously. Git also stores the full revision history of the code so that developers can easily track changes, fix bugs, and deploy new code using practices like continuous integration or continuous deployment.
A branch is a diversion from the main working project. By creating a new branch, the user can create a new version of the repo or experiment with changes that will not affect the base code. The most recent commit is considered the head of that branch. If you are happy with the changes you make in one branch, you can merge those changes into another branch.
The master is the main branch in a project. Akin to the trunk of a tree from which all other branches start. The master is where the final, error-free code is stored. Every Git repository has a main branch. You can create new parallel branches off the master branch, empowering you to do work without affecting that mainline.
A "repository" is simply a folder structure stored in Git. The "root" of a repository is the base folder you want to keep. A repository is different from a typical directory only because it stores context about the changes to the root folder and all of the subfolders under the root.
When you "create a repository," you are essentially creating a root folder that you can add subfolders to. When someone "clones" a repository, they are copying the root folder of your repository and all of its subfolders to their machine, along with the history of changes to that folder.
Example: As part of your team’s workflow, you create a new repo for each manufacturing site. Typically, in the controls world, we use one repository to represent a project for a client, a manufacturing site, or a zone within a manufacturing site. However, as you grow more comfortable with Git, we expect you'll define your own best practices that make sense for your organization.
A copy of the repository local to your workstation.
A copy of the repository that is centrally located in the cloud or on a server. It is where you push changes for collaboration and backup.
A commit is a recorded change to a file (or set of files), along with a message from a user describing the changes. It is often thought of as a snapshot or version of your repository at specific times. Commit can also be used as a verb which refers to the action of storing a new snapshot of the project’s state. Commits only create a snapshot in your local repository. To synchronize these changes to the remote repository you must Push. As a best practice, commits should be made frequently and after each change.
A push is a command used to add your commits from your local repository to a remote repository. A push is the opposite of a fetch.
A pull request occurs when you alert others about or request a review of a change you’ve pushed to a remote repository. The changes can be discussed, reviewed, and commented on, with follow-up commits added before the changes are merged into the main branch. The intent of the pull request is to merge changes into the master branch.
The fetch command is used to download commits and repos from the cloud, or remote repository, to your local repo. Multiple branches can be fetched at once.
A copy of an existing repository. The clone can be made as a branch or downloaded to your local repository from a remote repository. You are required to create a clone in order to work on a repository.
Merging combines two branches. Typically, commits made to a branch are merged into the master branch after being reviewed via a pull request. In some organizations, a project manager is responsible for approving merges.
To stash is the ability to pause multiple changes to files you may be working on. This allows you to make individual commits instead of one combined commit with multiple changes. You can call any of the changed files when you are ready to begin working on them again.
Copia allows you to protect important branches by setting branch protection rules. For example, collaborators can be required to have at least one pull request reviewed and approved before merging. The branch can also be protected from deletion.
Every repository has its own issue section. The issue section functions as a tracker which can be used to track bugs, tasks, or other enhancements. Copia issues allow collaborators to comment, tag, reference past issues, and upload associated files.
Every repository has its own wiki section, which can serve as a database, community resource, or content management tool. The wiki section allows collaborators to create, modify or delete pages related to the repo.
A diff in Git takes two data sets—like files, commits, or branches—and shows what has changed between them.
The action of looking at the changes between two commits.
A revert creates a new commit that undoes changes made in a past commit. This avoids having to make a deletion or orphan other commits on a branch.
The origin is the remote repository from which a clone was originally copied.
A top-level name of the business that is licensing Copia and indicates data ownership. Typically this is a company name, but in larger organizations may be a division or business unit.
A group of people that are permitted to have access to a repository. Users can have read/write, read-only, and administrator privileges. Teams can consist of people from different companies; for example, you can have a team made up of employees and subcontractors.
Now that you have reviewed the main terms in a Git workflow, you can see them in action by watching this video: