User Tools
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
cs:git:start [2016/08/19 21:07] Sean Kallaher [Branches] |
cs:git:start [2017/09/11 15:47] Sean Kallaher [Rebase/Integration Method] |
||
|---|---|---|---|
| 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:software_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. How we use git is very much tied to the overall [[:cs:sw_workflow/|software development workflow]], so I recommend reading that as well. |
| ===== Getting Started ===== | ===== Getting Started ===== | ||
| - | I highly recommend you start out by going over our intro tutorial to git, which describes a few high-level concepts that are important to understand before you start using git. For reference, you can find the official git documentation [[https://git-scm.com/doc|here]]. | + | I highly recommend you start out by going over our intro tutorial to git, which describes a few high-level concepts that are important to understand before you start using git. For reference, you can find the official git documentation [[https://git-scm.com/doc|here]]. An interactive tool for learning Git is [[http://try.github.io|Try Git]]. |
| 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". |
| - | + | ||
| - | 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 name with your name. For example, if I was working on thruster code, I would name my branch "james/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 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 dev. |
| - | * ''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> |
