README.md in git_reflow-0.8.10 vs README.md in git_reflow-0.9.0
- old
+ new
@@ -6,11 +6,11 @@
<p>
<a href="https://circleci.com/gh/reenhanced/git-reflow/tree/master" title="current build status">
<img alt="Circle CI" src="https://circleci.com/gh/reenhanced/gitreflow.svg?style=svg&circle-token=d94825c17c7e33558dc2a82b37afad7b558e5a12">
</a>
<a href="https://github.com/reenhanced/gitreflow" title="git workflow">
- <img alt="Git workflow powered by git-reflow" src="https://img.shields.io/badge/git--reflow-v0.8.10-blue.svg?style=flat">
+ <img alt="Git workflow powered by git-reflow" src="https://img.shields.io/badge/git--reflow-v0.9.0-blue.svg?style=flat">
</a>
<a href="http://inch-ci.org/github/reenhanced/gitreflow" title="documentation coverage">
<img src="http://inch-ci.org/github/reenhanced/gitreflow.svg?branch=master&style=shields" alt="Git-Reflow Documentation" />
</a>
</p>
@@ -115,11 +115,11 @@
git reflow start nh-branch-name
`git reflow start` takes in the name of the new branch name that you want to create your feature on.
In addition, it takes in an optional flag of a _base-branch_ name (`--base`). If you don't pass in this parameter,
-then it defaults to "master". The base branch name is the base branch that you want to base your feature off of.
+then it will look up the `reflow.base-branch` git configuration or default to "master". The base branch name is the base branch that you want to base your feature off of.
This ensures that every time you start a new base branch, it will be based off of your latest remote base.
git reflow start nh-branch-name --base base-branch-name
> **[PROTIP]** Use your initials at the beginning of each branch so your team knows
@@ -135,10 +135,13 @@
git reflow refresh -r <remote-location> -b <base-branch>
```
You pass in the name of the remote to fetch from and the name of the **base-branch** that you would like to merge into your **feature-branch**. The **remote-location** defaults to `origin` and the base-branch defaults to `master`. This command also takes in remote and branch name as flag options.
+> **Note:** If no `base-branch` argument is provided, then we'll look for a `reflow.base-branch` git
+> configuration and fallback to `master` as the default.
+
### Reviewing your work
```
git reflow review
```
@@ -148,13 +151,15 @@
The `review` step creates a pull request for the currently checked out feature branch against master. That's all you want to do most of the time.
We assume you know what you're doing, so if you need something different, do it by hand.
After making commits to your branch, run `review`. Didn't push it up? No problem, we'll do it for you.
```
-git reflow review -t <title> -m <message>
+git reflow review -t <title> -m <message> <base-branch>
```
-> **Note:** `-t` and `-m` are optional.
+> **Note:** `-t` and `-m` are optional, as is the `base-branch` argument. If no
+> base-branch is provided, then we'll look for a `reflow.base-branch` git
+> configuration and fallback to `master` as the default.
If you do not pass the title or message options to the review command, you will be given an editor to write your PR request commit message, similar to `git commit`. The first line is the title, the rest is the body.
```
$ git reflow review
@@ -200,13 +205,16 @@
If not, create it and print "Pull request created at http://pull-url/". If so, print the url for the existing request.
### Checking your branch status
```
-git reflow status
+git reflow status <base-branch>
```
+> **Note:** If no `base-branch` is provided, then we'll look for a `reflow.base-branch` git
+> configuration and fallback to `master` as the default.
+
Sometimes you start working on a branch and can't get back to it for a while. It happens. Use +status+ to check on the status of your work.
```
$ git reflow status
@@ -224,14 +232,17 @@
to find out where your pull request is at. But in case you want to take a look, we give you the option to open it for you.
### Delivering approved code
```
-git reflow deliver
+git reflow deliver <base-branch>
```
-> **Note:** This documentation is for the process for the github "remote" merge process via the github_api.
+> **Note:** If no `base-branch` argument is provided, then we'll look for a `reflow.base-branch` git
+> configuration and fallback to `master` as the default.
+
+> **Also:** This documentation is for the process for the github "remote" merge process via the github_api.
For the bitbucket standard or github manual process (used when the user applies -f force flag to the "remote" merge via the github_api), please go to section B.
You kick butt. You've got your code reviewed and now you're ready to merge it down to `master` and deploy. Reflow's `deliver` command will take care of all of the steps for you to make this happen.
@@ -440,9 +451,18 @@
```
git config --global --add "reflow.always-deliver" "true"
```
See our [Advanced Usage](https://github.com/reenhanced/gitreflow/wiki/Full-List-of-Configuration-Options) for more ways you can customize your workflow.
+
+## Customization
+
+Git-reflow's default process isn't meant to fit every team, which is why we've introduced [Custom Workflows](https://github.com/reenhanced/gitreflow/wiki/Custom-Workflows). With a custom workflow, you can:
+
+* Add hooks to be run before, or after any command
+* Use one of our pre-configured workflows as a basis for your own
+* Override any of the default commands
+* Create new commands
---
## Contributing
Pull requests are welcome. Please fork and submit. We use this tool every single day and as long as what you want to add doesn't change our workflow, we are happy to accept your updates. Feel free to add your Github username to the list below.