Version Control
Git Overview
Git is a version control system that enables you to track changes to files. With Git, you are able to revert files back to previous versions, restore deleted files, remove added files and even track down where a particular line of code was introduced.
Nearly all operations that are performed by Git are in your local computing environment, for the exception of few used purely to synchronize with a remote. Some of the most common git operations are depicted below.
If you would like to make any changes to current repository, it is always good to start with creating a feature branch, where you can save all the changes.
Create a Pull Request
Pull requests are useful before you merge your branch with the main branch. You can request a review from your colleagues and check for any conflicts with the main branch. After you pushed all the changes to your branch, you can go to the original GitHub repository and click on the pull request.
Stay up-to-date with Honeycomb template repo
Honeycomb is an active project, and will be updated with new features over time. To bring changes from the Honeycomb template repository to your task:
-
Add Honeycomb as an additional remote as follows:
git remote add honeycomb https://github.com/brown-ccv/honeycomb.git
-
Fetch the changes made to Honeycomb
git fetch --all
-
Merge the current Honeycomb repo
git merge honeycomb/main --allow-unrelated histories
There will almost certainly be many "merge conflicts" when merging in changes form the template repository. It is tedious but extremely import to not accidentally overwrite your task when resolving these conflicts
Best Practices
Git Branches
-
main
is the default branch and where releases are made from. This branch should be in clean/working conditions at all times. This branch is protected and can only be merged from Pull Requests for topic branches. -
topic
branches are created for new features, fixes, or really any changes. E.g,fix-task-trial2-stuck-button
This flow is sometimes referred to as Feature Branch Workflow
Basic Workflow
We recommend using a simple flow based on following rules:
- Use topic/feature branches, no direct commits on main.
- Perform tests and code reviews before merges into main, not afterwards.
- Every branch starts from main, and targets main.
- Commit messages reflect intent.
Comment styles
We encourage using Commitizen, a great tool for recording descriptions of commits in a standardized format which makes it easier for people to understand what changed in the code.
Cheatsheet
Git Commands
Command | Brief |
---|---|
git add <files> | add a file to next commit (stage) |
git commit -m <message> | commit staged files |
git push | upload staged commit to repo |
git pull | get remote repo commits and download (try and resolve conflicts) |
git clone <url> | download entire repository |
git checkout <branch> | checkout and create the branch you want to use |
# create branch with your feature
git checkout -b feature_name
# check the status of your repositoey
git status
# commit file contents to the local repository
git commit -m "My feature is ready"
# specific message
# push file contents to the remote (i.e. cloud) repository
git push origin feature_name
Alternative options
VS Code
Most IDEs have some built in tools for working with Git and VS Code is no exception. Check out this overview of source control in VS Code!
GitHub Desktop
GitHub Desktop is a GUI application for working with git. It is one of the programs installed as a prerequisite of Honeycomb. Check out this overview of source control in GitHub Desktop!