Week 2: Git, VSCode, and Intro to Java

This week, we'll get comfortable with the basic Git workflow in VSCode and write our very first lines of Java code.

Goals for this week:

• Learn how to use the VSCode Git integration.

• Write and run a simple "Hello, World!" program in Java.

• Learn about basic Java syntax, variables, and data types.

Tasks:

1. Git and VSCode Practice

• Clone the training repository:

  • In VSCode, open the Command Palette (Ctrl+Shift+P).

  • Run Git: Clone.

  • Paste the repository URL (you'll get this from a lead).

  • Choose a location on your computer to save the project.

• Create a branch: In the Command Palette, run Git: Create Branch, name it descriptively (e.g., arm-io-layer).

• Make a change:

  • Create a new file in this directory called Test.java.

  • Add the "Hello World" code from the Java section below into this file.

• Stage and commit your change:

  • Open the Source Control view in VS Code (branch icon in the Activity Bar).

  • You should see your new file listed under "Changes".

  • Click the + icon to stage the file.

  • Enter a commit message (e.g., "Add Hello World program").

  • Click the checkmark icon to commit.

• Push your change:

  • Click the button with the up arrow to push your commit to GitHub.

• Pull changes:

  • If other people have pushed changes, you'll see a down arrow with a number. Click this to pull their changes.

  • You can use the Command Palette actions Git: Push and Git: Pull instead of the toolbar buttons.

2. Your First Java Program

• "Hello, World!"

  • In your Test.java file, type the following code:

public class Test {

    public static void main(String[] args) {

        System.out.println("Hello, World!");

    }

}

• Run the program:

  • The Extension Pack for Java you installed should add a "Run" button above the main method. Click it!

  • You should see "Hello, World!" printed in the terminal.

3. Java Fundamentals

• Variables and Data Types:

  • We'll learn about the basic building blocks of Java:

    • int: for whole numbers (e.g., int myNumber = 5;)

    • double: for decimal numbers (e.g., double myDouble = 5.99;)

    • boolean: for true/false values (e.g., boolean isJavaFun = true;)

    • String: for text (e.g., String myText = "Hello";)

• Try it yourself:

  • In your Test.java file, try creating some variables of different types and printing them to the console using System.out.println().

More Java

This is a more in-depth tutorial that gives a brief overview of the Java syntax and some of the features of the language.

Basic terminology

• Class: A blueprint for creating objects. It defines their properties and methods.

• Object: An instance of a class.

• Method: A function defined inside a class.

• Variable: A container for storing data values.

• public: A keyword that means the class or method can be accessed by any other class.

• static: A keyword that means the method belongs to the class, rather than an object of the class.

• void: A keyword that means the method does not return any value.

• main: The name of the method that is the entry point of a Java program.

Resources

• W3Schools Java Tutorial

• Codecademy Learn Java

• freeCodeCamp.org

• The Java Units Library

• Creating a Robot Program

Exercises

• Finish the "Hello World" and "Variables" sections of the W3Schools tutorial.

• Do some of the exercises at the end of the W3Schools sections.

Notes

• It's a good idea to get familiar with the Java syntax, as it will be used throughout the FRC season.

• Don't worry if you don't understand everything at once. The goal is to get a basic understanding of the language.

What's Next?

Next week, we'll dive deeper into Java, learning about conditional statements, loops, and arrays.

Basic Git

Git is a version control system, or a way for us to collaborate on code and manage having multiple versions of code working in parallel

While many modern cloud applications, like google docs, have some form of auto-save to the cloud, we don't necessarily want a single auto-updating version of our code. Instead we use a tool called Git to manage different versions of our files and save them to Github, which lets us share the codebase between computers. Instead of automatically syncing to Github, we save our code in small named chunks called commits. The named versions makes it easy to revert changes that break previously working behaviour and see when and by who code was written. Git also lets us have different versions, called branches, in progress in parallel. This means that while one person works on code for the autonomous, another could work on vision, for example.

Resources

Read one of the following:

• WPILib Git intro

• Github Git intro

Install the following:

• Windows Git install

• Linux/Mac Git install

Using Git in VSCode

There is a sidebar in VSCode that shows everything you need to know about the Git status of your current project. Assuming you've set up a project (see above for how to clone!) you should be ready to go!

First step: creating a branch

Open the command palette (Ctrl+Shift+P on Windows, Cmd+Shift+P on Mac) and type "Git: Create Branch". This will create a new branch and switch to it after you name it. Please name it something descriptive. So if you are working on the arm IO layer, call it something like arm-io-layer.

Second step: making changes

Now you can make changes to your code!

Be sure to test it regularly to make sure it builds without errors.

Third step: committing your changes

Open the git sidebar and you'll see all your changes. Type a descriptive message of your changes in the box and click commit to commit all your changes. If you only want to commit some changes, you can select the files you want to commit by selecting the "+" icon next to them and then doing the above.

Fourth step: pushing your changes

Click the "Push" button in the git sidebar to push your changes to the remote repository. Alternatively, you can use the command palette to push your changes.

Fifth step: pulling changes

If you are working on a team computer, you should pull changes from the remote repository to your local repository. Do this whenever you start working on a new feature or bug fix. You can use the Command Palette actions Git: Push and Git: Pull instead of the toolbar buttons.

Version Control Standards

Our team uses Git, through VSCode, hosted on GitHub.

We have a Github Organization (Team2537) where all of our robot code lives.

Each year, we create a new repository for the robot code. This repository is where all of the code for the robot lives. Here are some past years repositories:

• 2022 - Rapid React

• 2023 - Charged Up

• 2024 - Crescendo

We use branches within these repositories to manage different versions of the robot code and to develop features in parallel.

Special Branches

There are a few special branches that we use in our repositories:

• main - This is the main branch of the repository. We plan to push code to this branch about weekly during the build season. This code should be fully tested and ready to deploy.

• dev - This is the development branch. This is where we merge features and fix small bugs. When we are actually working on code in the workshop, changes will be done here. Code that is on the dev branch may not be fully tested, but should build and deploy successfully.

• [competition] - Every competition that we participate in will have a branch. This branch will be created the night before we go to competition, and should include the contents of main (and maybe dev) at that time. Over the course of the competition, we may have to make emergency changes to the code. These changes will be made on the competition branch, and then possibly merged back into dev when we get back to the shop. The name of the competition branch should be the name of the competition, words separated by hyphens. For example, the branch for the CHS District Severn competition is CHS-district-severn.

Feature Branches

Every new feature that we develop should be developed on a feature branch. This branch should be named after the feature that is being developed. For example, if we are developing a launcher subsystem, we might create a branch called launcher-subsystem. When the feature is complete, we will merge the feature branch into the dev branch through a Pull Request. You may not merge directly to dev. Each new feature branch should be created from the dev branch.

Pull Requests

A pull request is a proposal to merge a set of changes from one branch into another. In a pull request, collaborators can review and discuss the proposed set of changes before they integrate the changes into the main codebase.

There are three types of Pull Requests that we use:

• Feature Pull Request - This is a pull request that proposes to merge a feature branch into the dev branch. This pull request should be reviewed by at least one other team member before it is merged.

• Dev Pull Request - This is a pull request that proposes to merge the dev branch into the main branch. These pull requests should be initialized and merged by both Software Leads. We plan to do this about weekly during the build season.

Please make sure your code follows the code practices before creating a pull request. If you do not follow the code practices, your code may not be merged.

We also use other version control features:

Commits

Each commit should be a small, atomic change. This means that each commit should only change one thing. This makes it easier to review changes and to understand what has been done. If you need to make multiple changes to implement a feature, you should make multiple commits.

WIP Commits

On a feature branch, frequent commits are encouraged. If you commit incomplete work, prefix the message with WIP:. Before merging to dev, squash WIP commits into meaningful commits. Prefer Draft PRs for early feedback while work is in progress.

Tags

We don't use tags very often, but we may use them to mark important points in the codebase. For example, we might tag the autonomous code that we first get working on the robot with a tag like auto-working.

Issues

We use GitHub Issues to track absolutely everything. New feature? New issue. Bug? Issue. Need Documentation? Need Issue. Anyone can and should create issues on our robot's repository. For most Pull Requests, there will be an issue that the PR is addressing.

Projects!

We use GitHub Projects to track the progress of our robot code. Each project has columns for different stages of development. For example, we might have columns for "To Do", "In Progress", "Review", and "Done". Each issue should be assigned to a column.

Everyone should be able to see the progress of the robot code by looking at the project board.

The Software Lead(s) will keep the project board up to date.