Git is a commonly used version control system for software development. It allows developers to track changes in their code, collaborate with others, and roll back to previous versions if needed.
Here is an excellent video on how to begin using Git with GitHub: Beginner Guide
- Repository (“Repo”) - A directory that stores all the files, folders, and content needed for your project.
- Local repository - Where you keep your copy of a Git repository on your computer
- Remote repository - A secondary copy of a Git repository where you push changes for collaboration or backup.
- Commit - Stores a snapshot of the current state of the repository. Commits should be made at milestones through out a project.
- Pull - Downloading the changes from a remote repository.
- Push - Uploading your local changes to a remote repository.
- Fetch - Downloading the latest commit log from a remote repository, not the actual changes.
- Merge - Joining two or more commit histories.
- Branch - A seprate set of code changes. Typically used to safely experiment or develop new features without effecting the main branch.
- Origin - The default branch name for a remote repository.
- Head - The current commit of the repository.
- Repository titles should include the project name and the framework used.
- Repository titles should be written in pascal case eg. SmartShoe.
- When separating concepts
-should be used over_eg. SmartShoe-KiCad.
- Commit messages must have a subject line and may have a description.
- The subject line should start with Standard Terminology.
- The subject line should be capitalized and must not end in a period.
- The subject line should be written in imperative mood (Fix, not Fixed / Fixes etc.).
- The description should only contain explanations as to what and why, never how. The latter belongs in documentation and implementation.
| First Word | Meaning |
|---|---|
| Add | Create a capability e.g. feature, class, dependency. |
| Remove | Remove a capability e.g. feature, class, dependency. |
| Update | Update a capability e.g. feature, class, dependency. |
| Fix | Fix an issue e.g. bug, typo, accident, misstatement. |
| Refactor | A change that just refactors existing code. |
| Optimize | Refactor of performance, e.g. speed up code. |
| Start | Begin doing something; e.g. create a feature flag. |
| Release | Release a version must contain a version number. |
Use the subject line for a brief message about the commit. This should be written in an imperative tone (Fix, not Fixed / Fixes etc).
- Describe what change has been made.
- Always start with Standard Terminology.
- Always start with capitalized letter and do not end with a period.
Use the description to explain the background and reasoning, not the Implementation. You can save all fellow developers and your future self some time by explaining why you did what Instead of how you did it.
- Describe why a change is being made.
- How does it address the issue?
- What effects does it have?
- Describe any limitations of the current code.
- Do not assume the reader understands what the original problem was.
- Bullet points are okay.
- Descriptions are not always necessary.
In keeping with the standard output of git itself, all commit subject lines must be written using the present-tense.
Good
- Add feature X
- Refactor X for readability
- Update getting started documentation
- Remove deprecated methods
- Release version 1.0.0
Bad
- Fixed bug with Y
- Changing behavior of X
Ugly
- More fixes for broken stuff
- Sweet new API methods
- 42