User Tools
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
cs:git:start [2016/09/02 13:26] Brandon Kallaher [Getting Started] |
cs:git:start [2022/04/15 02:13] (current) Chris Nathman [Introduction] |
||
|---|---|---|---|
| Line 2: | Line 2: | ||
| ===== Introduction ===== | ===== Introduction ===== | ||
| - | Git is a powerful and useful tool, but if used improperly it can be a clusterfuck for managing code. This page is designed to serve as a basic introduction to git, outline how Robosub is using git, and links to helpful information. How we use git is very much tied to the overall [[:cs:sw_workflow/|software development workflow]], so I recommend reading that as well. | + | Git is a powerful and useful tool, but if used improperly it can be a clusterfuck for managing code. This page is designed to serve as a basic introduction to git, outline how Robosub is using git, and links to helpful information. |
| ===== Getting Started ===== | ===== Getting Started ===== | ||
| Line 13: | Line 13: | ||
| The workflow we use consists of a few types of branches. | The workflow we use consists of a few types of branches. | ||
| - | 1. ''dev'' - This branch can be assumed to always be stable, meaning the code in these branches should always compile, and should pass all unit/module tests. User branches are merged into dev after passing a code review. | + | 1. ''master'' - This branch can be assumed to always be stable, meaning the code in these branches should always compile, and should pass all unit/module tests. User branches are merged into master after passing a code review. |
| - | 2. ''master'' - In contrast to dev, this branch is considered to be super-stable, meaning it meets all the requirements of dev, and in addition the code has been verified via sucessful pool test. Dev leads master, and master catches up to dev whenever the code in dev is considered super-stable. | + | 2. ''user/feature branches'' - These types of branches are the main ones most people will be directly interacting with. When naming your branches, it's recommended to prefix the branch name with your name. For example, if John Doe was working on thruster code, he would name his branch "john/thruster". |
| - | + | ||
| - | 3. ''user/feature branches'' - These types of branches are the main ones most people will be directly interacting with. When naming your branches, it's recommended to prefix the branch name with your name. For example, if John Doe was working on thruster code, he would name his branch "john/thruster". | + | |
| ===== Rebase/Integration Method ===== | ===== Rebase/Integration Method ===== | ||
| Line 23: | Line 21: | ||
| - Users always work on their own branch | - Users always work on their own branch | ||
| - | - When users feel their code is stable, they rebase onto the devbranch | + | - When users feel their code is stable, they rebase onto the master branch |
| - A code review will be set up, possibly resulting in software tweaks (back to step 1) | - A code review will be set up, possibly resulting in software tweaks (back to step 1) | ||
| - | - An integrator will fast-forward the dev branch up to the user’s branch | + | - An integrator will fast-forward the master branch up to the user’s branch |
| - | Integrators are a small group of people that control what code ends up going into the dev branch and keep the git repo clean. This group should only be a few people, possibly even just one person for each repository. Team leads might be a good person for this position. | + | Integrators are a small group of people that control what code ends up going into the master branch and keep the git repo clean. This group should only be a few people, possibly even just one person for each repository. Team leads might be a good person for this position. |
| The day-to-day workflow for users is as follows: | The day-to-day workflow for users is as follows: | ||
| Line 49: | Line 47: | ||
| Users often go long periods without commiting their work, because they feel like small changes are not worth committing. They wait until a substantial amount of changes have occurred, which can range from a few days to a few weeks. This is bad! This results in others not being aware of work that the user is doing, and also risks work getting lost. Users should at a **minimum** commit whatever they have done at the end of their current work session that day. | Users often go long periods without commiting their work, because they feel like small changes are not worth committing. They wait until a substantial amount of changes have occurred, which can range from a few days to a few weeks. This is bad! This results in others not being aware of work that the user is doing, and also risks work getting lost. Users should at a **minimum** commit whatever they have done at the end of their current work session that day. | ||
| - | Some may complain that this will result in a cluttered git history, however the solution for this is simple. When code is ready to be put into an integration branch, the user should perform an interactive rebase, and at that time they can squash together multiple commits into a single commit. By doing this a user can have 15 commits on their own branch (useful when they are developing), but when they believe their added feature is good and stable they can squash-rebase onto dev, and have single commit representing all the changes for the added feature. This results in a very clean and descriptive history when looking at the dev branch. | + | Some may complain that this will result in a cluttered git history, however the solution for this is simple. When code is ready to be put into an integration branch, the user should perform an interactive rebase, and at that time they can squash together multiple commits into a single commit. By doing this a user can have 15 commits on their own branch (useful when they are developing), but when they believe their added feature is good and stable they can squash-rebase onto master, and have single commit representing all the changes for the added feature. This results in a very clean and descriptive history when looking at the master branch. |
| ===== What Files to Commit? ===== | ===== What Files to Commit? ===== | ||
| Line 56: | Line 54: | ||
| ===== Quick reference ===== | ===== Quick reference ===== | ||
| * ''git fetch'' retrieve the latest changes from the server | * ''git fetch'' retrieve the latest changes from the server | ||
| - | * ''git rebase <other branch>'' rebase your current branch on top of <other branch>, which typically should be dev. | + | * ''git rebase <other branch>'' rebase your current branch on top of <other branch>, which typically should be master. |
| * ''git checkout <file/directory name>'' reset all unstaged changes to <file/directory name> | * ''git checkout <file/directory name>'' reset all unstaged changes to <file/directory name> | ||
