summaryrefslogtreecommitdiff
path: root/doc/workflow
diff options
context:
space:
mode:
authorSytse Sijbrandij <sytses@gmail.com>2014-10-14 13:21:42 +0200
committerSytse Sijbrandij <sytses@gmail.com>2014-10-14 13:21:42 +0200
commit5d59890b9de69a286f833f634f87fc18ddf0db7b (patch)
treeda8d86246ad9eb30c148e052c91579bf00ff674e /doc/workflow
parent672bd3902d86b78d730cea809fce312ec49d39d7 (diff)
downloadgitlab-ce-5d59890b9de69a286f833f634f87fc18ddf0db7b.tar.gz
Another link to GitHub flow.
Diffstat (limited to 'doc/workflow')
-rw-r--r--doc/workflow/gitlab_flow.md2
1 files changed, 1 insertions, 1 deletions
diff --git a/doc/workflow/gitlab_flow.md b/doc/workflow/gitlab_flow.md
index 70edea9c8d7..f8fd7c97e2a 100644
--- a/doc/workflow/gitlab_flow.md
+++ b/doc/workflow/gitlab_flow.md
@@ -26,7 +26,7 @@ After getting used to these three steps the branching model becomes the challeng
Since many organizations new to git have no conventions how to work with it, it can quickly become a mess.
The biggest problem they run into is that many long running branches that each contain part of the changes are around.
People have a hard time figuring out which branch they should develop on or deploy to production.
-Frequently the reaction to this problem is to adopt a standardized pattern such as [git flow](http://nvie.com/posts/a-successful-git-branching-model/) and [GitHub flow](https://guides.github.com/introduction/flow/index.html)
+Frequently the reaction to this problem is to adopt a standardized pattern such as [git flow](http://nvie.com/posts/a-successful-git-branching-model/) and [GitHub flow](http://scottchacon.com/2011/08/31/github-flow.html)
We think there is still room for improvement and will detail a set of practices we call GitLab flow.
# Git flow and its problems