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. As we're working, the changes we make can cause code to break very quickly in ways that might not be immediately obvious, which means it's good to be able to take a "snapshot" of the code at a point where it worked. So, 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. These 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, parallel versions, called branches, of code. This means that while one person works on code for the autonomous, another could work on vision, for example, without overriding each other.
Read one of the following:
Install the following:
- Typing
git add .thengit commit -m "commit name"thengit pushis the bread and butter of using Git. This sequence tells Git to collect all of your uncommitted changes, commit them, then push them to Github. If you'd like to combine these into one command, you can add an alias to your .gitconfig file (ask a lead or mentor for help). git checkout branch-nameswitches between branchesgit checkout -b new-branchmakes a new branch and switches to it. Note that the first time you push from this branch you will need to enter some extra parameters, but the terminal should prompt you with the correct command when you entergit pushgit statusdisplays the current branch and what changes you have uncommitted and stagedgit pullupdates the code on your device with the latest code from Github. Recommended to do this whenever someone else has been working on the same branch, otherwise you might make conflicting changes- A simple demo video of committing some changes
- Join Highlanders Robotics Github organization by asking Kevin to add your Github account
- Simple commit
- Clone this repository from Github
- Add your name to the list at the bottom of this file
- Commit and push those changes
- You may need to make an auth key for your account for this, ask a software lead or mentor for more help with this
- We use GitHub's pull request (PR) feature to manage branches and merges. Always make sure to merge to main using a PR. PR's will be explained further in the Git Workflow docs.
- Always commit code that at the very least compiles (you can check this by running the "Build robot code" option in WPILib's command bar)
- Commit messages should be short (~10 words), simple, and descriptive. If it's too long, use multiple lines in the commit message
- Commits should be frequent. Whenever you reach a working state, you should commit before you accidentally break anything again
- Don't commit directly to the
mainbranch, asmainshould always contain working code. New code should be developed on separate branches and can only be merged through a pull request after being reviewed and approved. - ALWAYS ALWAYS ALWAYS commit before you leave a meeting, especially if you are using a team computer! It is never fun to have to commit someone else's code at the start of the day or find out an hour in that you've been working off of someone else's uncommitted (potentially broken!) code. Uncommitted code also makes it harder to track what is and isn't finished.
- Run a
git statusat the start of a meeting to make sure whoever was there before you committed their code and that you are on the right branch
- Lewy
- Petro
- Sneha
- Aliya
- Athena
- Jerry
- Nathan
- Sam
- Viviane
- Jeffery
- Ariel
- Bora
- Jason
- Maxwell
- Dhilan
- Kai
- Ronan
- Ameliese