Version Control

and Communication

​

Week 2 Curriculum

Brain of a ChainLynxer

General Overview:

• What is Github, and why are we using it for version control?
• Tracking changes, pull requests, and comparing changes
• Resolving conflicting changes (please don’t branch!!!)
• Branches
• Discussing changes together on code team
• Committing (from the command line, Github Desktop, and the Github website)

​

​

​

​

Github

Github is a code hosting platform that allows teams to work collaboratively on projects (so we’re not overwriting each others’ changes and ensuring all components of our project are compatible with each other before merging them into the main branch of our repository).

1. Create a Github account and joining our organization
2. Summary of basic version control components
1. Repository: A datastore with the files for a project
2. Server: The computer storing the repository
3. Client: The computer accessing the repository
4. Main: The primary version of the code in the repository
5. Branch: A copy of one or more files for individual editing (e.g., so multiple people don’t make changes to the same file simultaneously)
6. Push origin: Applying changes made locally (in a code editor, etc.) to Github remote repository
7. Revert: Go back to the previous repository version by getting rid of local changes
8. Changelog: A record of all the changes made to the repository
9. Diff/change: Viewing the differences between two files (usually side by side)
10. Merge: Apply changes to a file
11. Conflict: When multiple pending changes to a file contradict each other

​

*highlighted sections are all git commands

Tracking and Comparing Changes

If you want to merge the changes you’ve written for a specific feature back onto the main branch, you need to submit a pull request, which puts your code up for review to be potentially approved and integrated into main.

Choose which branch you want to compare to main, and you can view the differences between the files they share in common below.

Once you are confident in your changes, click Create Pull Request. If your changes are denied for any reason, someone will discuss how to improve your code with you before you should submit another pull request.

To view commit history (person, commit name and body, date), click:

Resolving Conflicting Changes

Sometimes you may not be able to merge your changes because they contradict an earlier change (e.g., trying to remove or edit a file that no longer exists).

Sometimes you may not be able to merge your changes because they contradict an earlier change (e.g., trying to remove or edit a file that no longer exists). To resolve these conflicts, view the repository’s history/changelog and a diff (side by side comparison of the differences between your branch and the branch you want to merge into).

Example of a commit in history

Upon clicking on the commit’s name, a diff file will appear to view what was changed by that commit (you can similarly view this upon submitting pull request, but multiple files might be available for comparison).

Branches

There are a bunch of git commands that you can execute from the command line (partial list here: https://dzone.com/articles/top-20-git-commands-with-examples) if you a personal computer, but for now we’ll just stick with Github.

Branch (feature + immediate dependencies)

Main

As stated earlier, a branch is a set of code changes over one or more files that has been isolated for individual editing and testing before merging into another workspace (ex. into and from main, but you can also have a branch of a branch of a branch, etc.). However, you shouldn’t branch every time you want to commit something to a repository, as it’s often fine to directly commit to an already existing branch.

You should only branch when you have a new feature to contribute, such as a new subsystem or convenience feature (e.g., logging system). Before creating a new branch, check to see if you can integrate your code into one that already exists, to reduce clutter in the repository.

Should you branch for…

1. A new drivetrain subsystem
2. Testing changes for a specific event
3. Updating gradle

Note that you might not have admin permissions to branch (just ask someone who does to do so for you).

Discussing Changes

Open discussion time. We need to maintain active communication to optimize our productivity. Which of the following options sounds best to you? Feel free to suggest others.

• Discussing all pull requests and change proposals weekly or at every meeting
• Discussing all pull requests and change proposals among subteams at every meeting and bi-weekly among the entire code team

​

Committing Changes

With Github:

With Github Desktop:

Using the Command Line:

• git status (get working repository status)
• git add [filename(s)] (add changes]
• git commit -m “commit message” (commit changes)
• git push (push to main branch of remote repository)

Summarize what change you made in a few words

(don’t use the default commit message)