| title |
desc |
Determine the small feature to be coded |
Each new feature should be as small as possible, so that a single person can undertake the challenge.
|
|
| title |
desc |
Make a detailed Issue for the task |
Make a detailed Issue including adding it to a Sprint, assigning it to a single person & giving it appropriate labels. [See Agile project planning for more details.](/courses/web-dev-6/agile-project-planning/)
|
|
| title |
desc |
Pull |
Before branching, make sure you’re viewing the `master` branch, then you must pull the most recent code from the GitHub website so yours is up-to-date.
<br>`⌘⇧P`
|
|
| title |
desc |
Make a new branch for the task |
Make a new branch specifically for this feature, named after the task & Issue.
<br>`⌘⇧N`
|
|
| title |
repeat |
desc |
Write code & commit regularly |
true |
Write code and commit regularly. Be sure to follow the [Git commit best practices](/topics/commit-message-cheat-sheet). *It’s okay if the commits are incomplete because we’re coding on a separate branch it’s not going to affect the live website.*
<br>`⌘ Return`
|
|
| title |
desc |
Publish branch |
You can publish the branch to the GitHub website whenever you’re ready. Without a pull request the published branch just kinda sits there.
<br>`⌘P`
|
|
| title |
desc |
Create a detailed pull request |
When you’re ready for someone else to look at the code—even if it isn’t complete—make a pull request. Use pull requests as a discussion board. Follow the Sprint best practices and use labels, projects, milestones & assignees.
|
|
| title |
optional |
desc |
Resolve any conflicts |
true |
If there are any conflicts, because someone else edited the same code, resolve them using GitHub’s interface.
|
|
| title |
optional |
desc |
Pull conflict resolution merge |
true |
Because of the conflict resolution, code changed, so we need to make sure that your local feature branch is the most up-to-date version of the code. So pull again.
<br>`⌘⇧P`
|
|
| title |
desc |
Get a teammate’s review |
A teammate should now look of the code and decide whether to approve or reject the code.
- If the code isn’t good enough make detailed comments, even comment on specific lines.
- If the code is good, write a nice, positive message.
|
|
| title |
optional |
repeat |
desc |
Make more commits |
true |
true |
If the pull request was rejected, you (as the original author), must fix the code and create new commits. *You do not have to create a new branch, work on the same branch until this pull request is resolved.*
|
|
| title |
desc |
Merge pull request & delete branch |
When the code is approved, merge the pull request and delete the branch from GitHub’s website. The feature branch is no longer necessary because the code has been merged into `master`
|
|
| title |
desc |
Close the Issue |
Close the original task Issue and make sure the cards in the project board are in the “Done” column.
- Use `Fixes #80` or `Closes #77` in commit message descriptions to automatically close Issues.
|
|
| title |
desc |
Delete local branch |
The local feature branch, on your computer, is no longer needed so delete it from your computer too.
|
|
| title |
desc |
Pull |
Finally, make sure the code inside your repository is the most up-to-date version by pulling.
<br>`⌘⇧P`
|
|