Setting up a repository
Back in the day, being the sole developer on the robot, you did not have enough time to set the project up in a future-proof way. The robot code, for now, resides in a directory on your computer. Now that another developer (Bob) is joining the project, it is time to start version-controlling the robot code to make collaboration more efficient.
When working on content, be it code or another form of written text, wouldn't it be great to see what was changed, when, and by whom? Or to travel back in time to a certain point before a change was introduced? To try some crazy idea with the ability to come back to the original version, if the idea proved to be too ambitious? Think of the "undo" operation in many programs, but more powerful.
Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. - Git documentation
Version control systems are designed to make collaboration on content efficient. Version control is useful even if you are the only one working on your project. If your code is versioned, you don't need to remember what you have changed since the last time you touched it. The version control system tracks all the changes you do. You can rewind the history if needed. You can create "alternative realities" to try some ideas without the fear of losing your precious code. Other people can join and predictably contribute to your project.
Git is a distributed version control system. In short, it means that everyone has the whole code repository and the change history on their machine. In theory, none of the repositories is the "correct" one. They are all complete, containing the full project. In practice, it is common to use a shared (typically remote) repository to which people contribute their code.
Typically the shared repository is hosted on a service such as GitHub, GitLab, or Bitbucket. Developers work in their local repositories on their computers and then provide their code for merging in the shared repository.
Using a hosted service is just a convention. You could decide to have the "main" repository on your computer. Other people could send their changes to you by email, Slack, or pigeon 🕊️, and you would merge the changes to your repository. Hosted services make this easier and provide other tools to support collaboration, too.
Get the robot code you have been working on in the previous course, and put it in a new directory on your computer. This location will become the home for your local Git repository.
If you do not have the code anymore, or you want to start from a clean slate, get the robot from Robocorp Portal.
Create a new remote Git repository, initialize your local repository, and push the existing robot to GitHub
Follow the Adding an existing project to GitHub using the command line to push the robot to your GitHub repository. In real life, your organization would probably provide you with a repository, or grant permission to create new repositories under your organization account. For the purpose of this course, you can think of your repository as the official RobotSpareBin Industries repository!
When setting up the GitHub repository, you might also want to set up GitHub Actions integrations to automatically deploy your robot to Control Room, responding for example to events like a new commit being pushed, a new pull request being created or merged.
Now that you have successfully set up the version control system, it's time to start the actual development!
But first, there is one important lesson ☝️. It might hurt a bit, but it is a good kind of hurt. The type that helps you grow as a professional software developer. No pain, no gain! 💪
- Using version control in your projects is a best practice, even when you are the sole developer.
- Git is the defacto standard distributed version control system.
- It is common to use a remote repository where people share their code.
- GitHub, GitLab or Bitbucket are some of the better-known service providers.