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, with the exception of a few used to synchronize with the GitHub remote host. 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.
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
. Note how the branch name describes the changes.
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.
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 -b <branch> | create and checkout a new branch |
git checkout <branch> | checkout 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
GUI Based Source Control
- VS Code is the default IDE installed by Honeycomb. Check out this overview of source control in VS Code!
- GitHub Desktop is a GUI application built specifically 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!
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 from the template repository. It is tedious, but extremely import, to not accidentally overwrite your task when resolving these conflicts.