Sie sind auf Seite 1von 3

GitFlow General Guidelines

1. Git-flow: A successful Git branching model


http://nvie.com/posts/a-successful-git-branching-model/
2. General work with GitFlow
Features should be developed using feature branches. Depending on the release policy,
features are being grouped into releases for a deploy.
For emergency issues a release branch should always be kept open. More details below.
3. Hotfix branches

Hotfix branches should not be used in the current context. Their purpose is to correct issues
wherever older versions of the project are deployed. Since the same version of the project is
deployed for every client, there is no need for hotfix branches. The use of hotfix branches is
therefore forbidden.
4. Release branches

Release branches are used to group features together for a deploy.


For any emergencies a release branch will be kept open. All issues will be resolved on this
branch, while still being able to work on features that will not go in this release.

Deploys are done by hard reset of the deploy/production, deploy/staging, deploy/QA.


If a release branch is open (for urgent issues), the deploy branches will be hard reset to the
last commit on this branch.
When enough features are being developed, the current release (the one for urgent issues) is
closed. After this the deploy branches should be hard reset to the latest commits on master
and develop (deploy/production -> master, deploy/staging -> master or devel, deploy/QA ->
devel).

Now a new release can be started with the features developed after the intermediate release
was opened.
5. Deploy branches
NOTE: Direct commits on deploy branches are forbidden.
Whenever doing hard reset on deploy branches, the following situation may occur:

This usually occurs when commits are made on a branch without fetching changes from the
remote branch, but someone else has already pushed other changes to the same remote
branch.
This situation will also occur when hard resetting a deploy branch that was pointing to the
master branch, to a commit that is pointing to a commit in an ongoing release branch.
To fix this you need to force push your local deploy branch to origin.

CAUTION! By force pushing your local branch to the remote branch you will override all
remote tracked content. Force push should only be used on deploy branches.
6. Main branches
Whenever closing feature branches, or making commits on devel branch, make sure you have
pulled all the remote changes to your local devel branch.
To check for any remote changes, use the fetch command. If changes are present on remote
use the pull command.
Whenever you are pulling changes to a local branch, make sure you have the following option
unchecked: Commit merged changes immediately.

7. Release management
Caution! Before making any rebase operation it is recommended to create backup branches for

each of the affected branches


In order to release selective commits made on the develop branch the following basic process
can be applied:
- Create a new temporary branch from the develop branch (new_release in the current
example)
- While on the newly created branch, interactively rebase the desired commits over the
current release branch

- Choose the commits that need to be put into the release and delete the rest

- Conflicts most probably will occur during the rebase process. These conflicts need to be
solved with the involvement of the developer
- After solving the conflicts the chosen commits will show up on the newly created branch

- Next the release needs to be hard-reset to the latest commit on the new_release branch

- Next the commits that were put on the release branch need to be removed from the develop
branch in order to avoid duplicate commits when closing the current release branch. In order to
do that the develop branch needs to be interactively rebased from the point where the current
release branch was started

- The commits that were on moved to the release branch need to be deleted

- After removing the commits and resolving the inevitable conflicts the develop branch will
contain all the commits minus the ones on release

Das könnte Ihnen auch gefallen