- 09 Jul, 2010 4 commits
-
-
Vincent Driessen authored
This new subcommand lets you easily work together with peers on features. It's intended to be extremely simple to pull changes from your co-developers. This implementation may also be ported to release and/or hotfix branches in the near future, if we agree on the final implementation details. Example use =========== Sharing development of feature branches goes as follows: Suppose Alice and Bob are both developers on project Foo. They have local repos that are up-to-date with `origin`. Then, Alice starts working on some feature: alice$ git flow feature start newprotocol Switched to a new branch 'feature/newprotocol' ... Then, she hacks on the new feature, commits as desired, until the feature's finished. She then likes Bob to code-review the feature, so she asks Bob to pull from her. (Assuming Bob has a Git remote defined, pointing to Alice's repo.) bob$ git remote alice bob$ git branch * develop feature/reader master bob$ git flow feature pull alice newprotocol Created local branch feature/newprotocol based on alice's feature/newprotocol. bob$ git branch develop * feature/newprotocol feature/reader master Since the new feature branch is already checked out, Bob can immediately start peer reviewing the code. He changes the code as desired and commits each comment individually, so Alice can later read the Git commit log as the peer review log. bob$ git commit [feature/newprotocol 1f6fa95] Forgot return statement. 1 files changed, 1 insertions(+), 1 deletions(-) ... When he's finished, he tells Alice he's done. Alice then, in turn pulls in the peer review commits from Bob, using the same command Bob used to fetch the changes initially. (Because feature/newprotocol is still her current branch, she may omit the explicit 'newprotocols' argument.) alice$ git flow feature pull bob Pulled bob's changes into feature/newprotocol. If she disagrees with Bob's comments, she may again commit changes and ask Bob to do the same again. This leads to a continuous pull cycle until both parties agree on the final implementation. Then, Alice (as the feature owner) finished the feature. Bob may discard his feature branch. -
Vincent Driessen authored
-
Vincent Driessen authored
-
Vincent Driessen authored
Before this change, `git-flow feature start` would nag about the working tree being dirty and disallow continuation. Then, there were two alternatives: - stash away your changes manually, create the new branch, restore the stash; or - use `git-flow feature start -f` to force creation There is absolutely no good reason for git-flow to forbid this creation, as git allows it already. Therefore, the -f behaviour is now the default, without an option to turn that behaviour off. Git takes care of unsafe situations again now.
-
- 08 Jul, 2010 2 commits
-
-
Vincent Driessen authored
This fix also works when feature branches are created manually, based on remote (i.e. other developers) feature branches, to work on features together. `git branch -d` won't remove local feature branches that are set up to track remote branches, `-D` will. Fixes ticket #31.
-
Vincent Driessen authored
Sorry!
-
- 05 Jul, 2010 1 commit
-
-
Vincent Driessen authored
-
- 29 Jun, 2010 2 commits
-
-
Randy Merrill authored
-
Randy Merrill authored
-
- 27 May, 2010 3 commits
-
-
Vincent Driessen authored
-
Vincent Driessen authored
-
Vincent Driessen authored
This can be used as a shortcut to "git checkout feature/full-feature-name". Feature branch prefix names may be used for convenience.
-
- 04 Apr, 2010 6 commits
-
-
Vincent Driessen authored
Only test if local branch is behind origin if origin exists.
-
Vincent Driessen authored
-
Vincent Driessen authored
-
Vincent Driessen authored
-
Vincent Driessen authored
-
Vincent Driessen authored
-
- 01 Apr, 2010 1 commit
-
-
gmallard authored
-
- 25 Mar, 2010 2 commits
-
-
Vincent Driessen authored
They were left behind in the main git-flow script, since they are moved over to gitflow-common.
-
Vincent Driessen authored
-
- 23 Mar, 2010 2 commits
-
-
Vincent Driessen authored
-
Vincent Driessen authored
new repo is created.
-
- 19 Mar, 2010 3 commits
-
-
Vincent Driessen authored
-
Vincent Driessen authored
``prefix''. There is no need to install git-flow inside git's libexec dir by default. It just needs to be *somewhere* on the PATH.
-
Vincent Driessen authored
-
- 24 Feb, 2010 6 commits
-
-
Vincent Driessen authored
-
Vincent Driessen authored
-
Vincent Driessen authored
-
Vincent Driessen authored
-
Vincent Driessen authored
-
Vincent Driessen authored
-
- 22 Feb, 2010 7 commits
-
-
Vincent Driessen authored
-
Vincent Driessen authored
-
Vincent Driessen authored
-
Vincent Driessen authored
-
Vincent Driessen authored
-
Vincent Driessen authored
functions, then gitflow-specific functions and finally, assertions to use in gitflow subcommands.
-
Vincent Driessen authored
git specific and git-flow specific functions: gitflow_current_branch -> git_current_branch gitflow_is_branch_merged_into -> git_is_branch_merged_into gitflow_local_branch_exists -> git_local_branch_exists gitflow_local_branches -> git_local_branches gitflow_remote_branches -> git_remote_branches gitflow_require_branch -> require_branch gitflow_require_branch_absent -> require_branch_absent gitflow_require_branches_equal -> require_branches_equal gitflow_require_clean_working_tree -> require_clean_working_tree gitflow_require_git_repo -> require_git_repo gitflow_require_git_repo -> require_git_repo gitflow_require_initialized -> require_gitflow_initialized gitflow_require_initialized -> require_gitflow_initialized gitflow_require_local_branch -> require_local_branch gitflow_require_remote_branch -> require_remote_branch gitflow_require_tag_absent -> require_tag_absent gitflow_tag_exists -> git_tag_exists gitflow_test_branches_equal -> git_compare_branches gitflow_test_clean_working_tree -> git_is_clean_working_tree resolve_nameprefix -> gitflow_resolve_nameprefix
-
- 21 Feb, 2010 1 commit
-
-
Vincent Driessen authored
GIT_EXEC_PATH overrideable via Makefile command arguments.
-