# A Good Team Git Workflow

## Introduction

The three main sections below outline a common Git workflow for doing the main three things we do:

- Start a new feature branch.
- Grab changes from finished feature branches.
- Release a new version of the overall app.

### A Short Talk About Branch Names

We'll be using `snacks-edit-form` as an example, but you would name your branch after whatever feature you're working on.

We'll also be using `dev` as the name for our Development branch, and `main` for our releases. But they could be called anything, as long as you have branches that fill that role.

The most important naming convention is that your branch names have small, clear scope. Not `work-on-back-end` or `make-database` or `fix-react`, but instead, `create-basic-routes` or `set-up-database-seeding` or `refactor-state-in-new-snack-form`. And definitely not names that aren't task names—no branches named after their creators, please!

All of this will be very important when you're working on professional teams.

## Starting A New Feature

Let's say you are creating a feature for your app: an edit form for the user's chosen snack. We'll walk through creating and using a branch called `snacks-edit-form` here.

- Switch to the Development branch (`git switch dev`).
- Pull down any changes (`git pull origin dev`). This is necessary even if you are the last person whose features were merged in, since your local Development branch won't include the changes the remote Development branch has.
- While on the Development branch, create a new branch with the name of your feature (`git switch -c snacks-edit-form`). Creating it from the Development branch is important, since that will mean it will start off from ("branch" off of) the newest Development branch code.
- Work until you're done with the feature, adding, committing, and pushing to the remote (`git push origin snacks-edit-form`) as you go.
- When you're done with your feature, and you've pushed one last time, go to GitHub and open a PR from your branch to the Development branch (`dev`).
- Ask your teammate to give it a look-over and merge it.
- If it takes them a while to get around to it, **Do NOT wait.** You can start at the top of these steps and begin another feature in the meantime. It is _very_ important that you not waste Git's ability to allow work to be fully asynchronous go to waste. Grab another feature and start working on it!
- Optional but highly encouraged: once your teammate has merged your feature branch into the Development branch, delete your feature branch from your machine and GitHub (`git branch -d snacks-edit-form` and then `git push origin --delete snacks-edit-form`). This prevents your list of branches in your app's repo from sticking around forever and accumulating forever. Your feature branch is no longer necessary, since the code is in `dev` now.
- Repeat these steps for the next feature.

## When A Feature Is Merged Into Development

For the sake of this section, let's say you're working on adding a `beverages` table on the back end. (We'll call this feature branch `beverages-table`.) Meanwhile, another teammate has finished their feature. **Let's make sure you and everyone else has that new code in the feature they're working on.**

- Another teammate (possibly you!) should go to GitHub, give the Pull Request a quick look-over/sanity check/smell test, then merge it.
- Once it's merged, everyone (including the teammate who submitted the PR!) should go to their Development branch and pull down (`git switch dev` and `git pull origin dev`).
- Switch to the feature branch you're working on (`git switch beverages-table`).
- Merge the changes you pulled down into your local Development branch into the feature branch you're currently working on (`git merge dev`). _If there will be a merge conflict, this is where it will happen._
- Deal with a merge conflict if it occurs, and either way, you've got all the changes, you're already on your feature branch, and so you can get right back to implementing your feature, knowing you're working with the up-to-date Development branch code.

## When Your Team Is Ready For A Release Version.

You've added a number of features and you're ready to say, "This is a new version!" Some teammates may well be working on features that go into the _next_ version still, but what you've got in the Development branch feels major enough.

- Meet with your team, all together, and thoroughly test the Development branch. This is best done by:
- Switching to the branch on someone's machine (`git switch dev`).
- Pulling down all changes (`git pull origin dev`).
- Testing the features, ensuring they pass both automatic tests and whatever manual tests you can think to throw at it.
- If anything's not working, then you need a fixing branch, which should likely be assigned to whoever can best fix the issues, which is generally the person most familiar with the non-working code, possibly pairing with someone to get another set of eyes on it. Start a new branch called, say, `fix-create-snack`, and follow all the steps from the "Starting A New Feature" section above. Work on that until you think you've fixed the issues, open a PR to the Development branch, and start back at the first bullet point in this section. It's time to get everyone's eyes on the Development branch again and see if it's ready to be released!
- Repeat the testing until everything's working.
- Once the team is sure the potential release is working the way you want it to be working, open a PR from the Development branch (`dev`) to the Production branch (`main`), and merge that PR in!
- Celebrate! You just released a thoroughly tested major version of your app. Nice.
- Get back to work. You'll celebrate again soon enough!
- _Everyone_ should now pull down to their local Production branch (`git switch main` and `git pull origin main`).
- Everyone should merge those changes into their Development branch to be absolutely sure (`git switch dev` and `git merge main`).
- And then merge those changes into whatever you're working on now as well (`git switch [your feature branch]` and `git merge main`).
- Get back to work on your current feature, or start a new one!