From 05a6115bc8f9ae3e3b41a155334adb6f73d5a0cc Mon Sep 17 00:00:00 2001 From: Ciro Santilli Date: Sat, 27 Dec 2014 21:43:43 +0100 Subject: doc workflow markdown style - add h1 to README - move h1 in workflow.md to h2 since the top image acts as h1 - typos --- doc/workflow/README.md | 2 ++ doc/workflow/gitlab_flow.md | 42 +++++++++++++++++++++--------------------- 2 files changed, 23 insertions(+), 21 deletions(-) (limited to 'doc/workflow') diff --git a/doc/workflow/README.md b/doc/workflow/README.md index c26d85e9955..f0e0f51b1ac 100644 --- a/doc/workflow/README.md +++ b/doc/workflow/README.md @@ -1,3 +1,5 @@ +# Workflow + - [Workflow](workflow.md) - [Project Features](project_features.md) - [Authorization for merge requests](authorization_for_merge_requests.md) diff --git a/doc/workflow/gitlab_flow.md b/doc/workflow/gitlab_flow.md index f8fd7c97e2a..1dbff60cbfd 100644 --- a/doc/workflow/gitlab_flow.md +++ b/doc/workflow/gitlab_flow.md @@ -1,6 +1,6 @@ ![GitLab Flow](gitlab_flow.png) -# Introduction +## Introduction Version management with git makes branching and merging much easier than older versioning systems such as SVN. This allows a wide variety of branching strategies and workflows. @@ -29,9 +29,9 @@ People have a hard time figuring out which branch they should develop on or depl 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 +## Git flow and its problems -[![Git Flow timeline by Vincent Driessen, used with persmission](gitdashflow.png) +[![Git Flow timeline by Vincent Driessen, used with permission](gitdashflow.png) Git flow was one of the first proposals to use git branches and it has gotten a lot of attention. It advocates a master branch and a separate develop branch as well as supporting branches for features, releases and hotfixes. @@ -50,7 +50,7 @@ Frequently developers make a mistake and for example changes are only merged int The root cause of these errors is that git flow is too complex for most of the use cases. And doing releases doesn't automatically mean also doing hotfixes. -# GitHub flow as a simpler alternative +## GitHub flow as a simpler alternative ![Master branch with feature branches merged in](github_flow.png) @@ -62,13 +62,13 @@ Merging everything into the master branch and deploying often means you minimize But this flow still leaves a lot of questions unanswered regarding deployments, environments, releases and integrations with issues. With GitLab flow we offer additional guidance for these questions. -# Production branch with GitLab flow +## Production branch with GitLab flow ![Master branch and production branch with arrow that indicate deployments](production_branch.png) GitHub flow does assume you are able to deploy to production every time you merge a feature branch. This is possible for SaaS applications but are many cases where this is not possible. -One would be a situation where you are not in control of the exact release moment, for example an iOS application that needs to pass AppStore validation. +One would be a situation where you are not in control of the exact release moment, for example an iOS application that needs to pass App Store validation. Another example is when you have deployment windows (workdays from 10am to 4pm when the operations team is at full capacity) but you also merge code at other times. In these cases you can make a production branch that reflects the deployed code. You can deploy a new version by merging in master to the production branch. @@ -78,7 +78,7 @@ This time is pretty accurate if you automatically deploy your production branch. If you need a more exact time you can have your deployment script create a tag on each deployment. This flow prevents the overhead of releasing, tagging and merging that is common to git flow. -# Environment branches with GitLab flow +## Environment branches with GitLab flow ![Multiple branches with the code cascading from one to another](environment_branches.png) @@ -93,7 +93,7 @@ If master is good to go (it should be if you a practicing [continuous delivery]( If this is not possible because more manual testing is required you can send merge requests from the feature branch to the downstream branches. An 'extreme' version of environment branches are setting up an environment for each feature branch as done by [Teatro](http://teatro.io/). -# Release branches with GitLab flow +## Release branches with GitLab flow ![Master and multiple release branches that vary in length with cherrypicks from master](release_branches.png) @@ -109,7 +109,7 @@ Every time a bug-fix is included in a release branch the patch version is raised Some projects also have a stable branch that points to the same commit as the latest released branch. In this flow it is not common to have a production branch (or git flow master branch). -# Merge/pull requests with GitLab flow +## Merge/pull requests with GitLab flow ![Merge request with line comments](mr_inline_comments.png) @@ -134,7 +134,7 @@ If the assigned person does not feel comfortable they can close the merge reques In GitLab it is common to protect the long-lived branches (e.g. the master branch) so that normal developers [can't modify these protected branches](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/permissions/permissions.md). So if you want to merge it into a protected branch you assign it to someone with master authorizations. -# Issues with GitLab flow +## Issues with GitLab flow ![Merge request with the branch name 15-require-a-password-to-change-it and assignee field shown](merge_request.png) @@ -168,7 +168,7 @@ In this case it is no problem to reuse the same branch name since it was deleted At any time there is at most one branch for every issue. It is possible that one feature branch solves more than one issue. -# Linking and closing issues from merge requests +## Linking and closing issues from merge requests ![Merge request showing the linked issues that will be closed](close_issue_mr.png) @@ -181,7 +181,7 @@ If you only want to make the reference without closing the issue you can also ju If you have an issue that spans across multiple repositories, the best thing is to create an issue for each repository and link all issues to a parent issue. -# Squashing commits with rebase +## Squashing commits with rebase ![Vim screen showing the rebase view](rebase.png) @@ -189,7 +189,7 @@ With git you can use an interactive rebase (rebase -i) to squash multiple commit This functionality is useful if you made a couple of commits for small changes during development and want to replace them with a single commit or if you want to make the order more logical. However you should never rebase commits you have pushed to a remote server. Somebody can have referred to the commits or cherry-picked them. -When you rebase you change the identifier (SHA1) of the commit and this is confusing. +When you rebase you change the identifier (SHA-1) of the commit and this is confusing. If you do that the same change will be known under multiple identifiers and this can cause much confusion. If people already reviewed your code it will be hard for them to review only the improvements you made since then if you have rebased everything into one commit. @@ -207,7 +207,7 @@ If you revert a merge and you change your mind, revert the revert instead of mer Being able to revert a merge is a good reason always to create a merge commit when you merge manually with the `--no-ff` option. Git management software will always create a merge commit when you accept a merge request. -# Do not order commits with rebase +## Do not order commits with rebase ![List of sequential merge commits](merge_commits.png) @@ -231,8 +231,8 @@ The last reason for creating merge commits is having long lived branches that yo Martin Fowler, in [his article about feature branches](http://martinfowler.com/bliki/FeatureBranch.html) talks about this Continuous Integration (CI). At GitLab we are guilty of confusing CI with branch testing. Quoting Martin Fowler: "I've heard people say they are doing CI because they are running builds, perhaps using a CI server, on every branch with every commit. That's continuous building, and a Good Thing, but there's no integration, so it's not CI.". -The solution to prevent many merge commits is to keep your feature branches shortlived, the vast majority should take less than one day of work. -If your feature branches commenly take more than a day of work, look into ways to create smaller units of work and/or use [feature toggles](http://martinfowler.com/bliki/FeatureToggle.html). +The solution to prevent many merge commits is to keep your feature branches short-lived, the vast majority should take less than one day of work. +If your feature branches commonly take more than a day of work, look into ways to create smaller units of work and/or use [feature toggles](http://martinfowler.com/bliki/FeatureToggle.html). As for the long running branches that take more than one day there are two strategies. In a CI strategy you can merge in master at the start of the day to prevent painful merges at a later time. In a synchronization point strategy you only merge in from well defined points in time, for example a tagged release. @@ -244,7 +244,7 @@ Developing software happen in small messy steps and it is OK to have your histor You can use tools to view the network graphs of commits and understand the messy history that created your code. If you rebase code the history is incorrect, and there is no way for tools to remedy this because they can't deal with changing commit identifiers. -# Voting on merge requests +## Voting on merge requests ![Voting slider in GitLab](voting_slider.png) @@ -252,7 +252,7 @@ It is common to voice approval or disapproval by using +1 or -1 emoticons. In GitLab the +1 and -1 are aggregated and shown at the top of the merge request. As a rule of thumb anything that doesn't have two times more +1's than -1's is suspect and should not be merged yet. -# Pushing and removing branches +## Pushing and removing branches ![Remove checkbox for branch in merge requests](remove_checkbox.png) @@ -266,7 +266,7 @@ This ensures that the branch overview in the repository management software show This also ensures that when someone reopens the issue a new branch with the same name can be used without problem. When you reopen an issue you need to create a new merge request. -# Committing often and with the right message +## Committing often and with the right message ![Good and bad commit message](good_commit.png) @@ -282,7 +282,7 @@ Some words that are bad commit messages because they don't contain munch informa The word fix or fixes is also a red flag, unless it comes after the commit sentence and references an issue number. To see more information about the formatting of commit messages please see this great [blog post by Tim Pope](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html). -# Testing before merging +## Testing before merging ![Merge requests showing the test states, red, yellow and green](ci_mr.png) @@ -299,7 +299,7 @@ If there are no merge conflicts and the feature branches are short lived the ris If there are merge conflicts you merge the master branch into the feature branch and the CI server will rerun the tests. If you have long lived feature branches that last for more than a few days you should make your issues smaller. -# Merging in other code +## Merging in other code ![Shell output showing git pull output](git_pull.png) -- cgit v1.2.1 From 43c2d5a2687bd45bb1f8e3f8390a7b558afb75a0 Mon Sep 17 00:00:00 2001 From: Marin Jankovski Date: Mon, 29 Dec 2014 10:44:08 +0100 Subject: Add documentation about protected branches. --- doc/workflow/README.md | 1 + doc/workflow/protected_branches.md | 33 +++++++++++++++++++++ .../protected_branches/protected_branches1.png | Bin 0 -> 170113 bytes .../protected_branches/protected_branches2.png | Bin 0 -> 25851 bytes 4 files changed, 34 insertions(+) create mode 100644 doc/workflow/protected_branches.md create mode 100644 doc/workflow/protected_branches/protected_branches1.png create mode 100644 doc/workflow/protected_branches/protected_branches2.png (limited to 'doc/workflow') diff --git a/doc/workflow/README.md b/doc/workflow/README.md index f0e0f51b1ac..8ef51b50b9d 100644 --- a/doc/workflow/README.md +++ b/doc/workflow/README.md @@ -8,3 +8,4 @@ - [GitLab Flow](gitlab_flow.md) - [Notifications](notifications.md) - [Migrating from SVN to GitLab](migrating_from_svn.md) +- [Protected branches](protected_branches.md) diff --git a/doc/workflow/protected_branches.md b/doc/workflow/protected_branches.md new file mode 100644 index 00000000000..805f7f8d35c --- /dev/null +++ b/doc/workflow/protected_branches.md @@ -0,0 +1,33 @@ +# Protected branches + +Permission in GitLab are fundamentally defined around the idea of having read or write permission to the repository and branches. + +To prevent people from messing with history or pushing code without review, we've created protected branches. + +A protected branch does three simple things: + +* it prevents pushes from everybody except users with Master permission +* it prevents anyone from force pushing to the branch +* it prevents anyone from deleting the branch + +You can make any branch a protected branch. GitLab makes the master branch a protected branch by default. + +To protect a branch, user needs to have at least a Master permission level, see [permissions document](permissions/permissions.md). + +![protected branches page](protected_branches/protected_branches1.png) + +Navigate to project settings page and select `protected branches`. From the `Branch` dropdown menu select the branch you want to protect. + +Some workflows, like [GitLab workflow](gitlab_flow.md), require all users with write access to submit a Merge request in order to get the code into a protected branch. + +Since Masters and Owners can already push to protected branches, that means Developers cannot push to protected branch and need to submit a Merge request. + +However, there are workflows where that is not needed and only protecting from force pushes and branch removal is useful. + +For those workflows, you can allow everyone with write access to push to a protected branch by selecting `Developers can push` check box. + +On already protected branches you can also allow developers to push to the repository by selecting the `Developers can push` check box. + +![Developers can push](protected_branches/protected_branches2.png) + + diff --git a/doc/workflow/protected_branches/protected_branches1.png b/doc/workflow/protected_branches/protected_branches1.png new file mode 100644 index 00000000000..5c2a3de5f70 Binary files /dev/null and b/doc/workflow/protected_branches/protected_branches1.png differ diff --git a/doc/workflow/protected_branches/protected_branches2.png b/doc/workflow/protected_branches/protected_branches2.png new file mode 100644 index 00000000000..2dca3541365 Binary files /dev/null and b/doc/workflow/protected_branches/protected_branches2.png differ -- cgit v1.2.1 From c92de64bdb057922ca6f243f36502bbf160b9ffc Mon Sep 17 00:00:00 2001 From: Valery Sizov Date: Mon, 19 Jan 2015 21:08:04 -0800 Subject: GitHub importer description --- doc/workflow/README.md | 1 + doc/workflow/github_importer/importer.png | Bin 0 -> 39335 bytes doc/workflow/github_importer/new_project_page.png | Bin 0 -> 46276 bytes doc/workflow/import_projects_from_github.md | 13 +++++++++++++ 4 files changed, 14 insertions(+) create mode 100644 doc/workflow/github_importer/importer.png create mode 100644 doc/workflow/github_importer/new_project_page.png create mode 100644 doc/workflow/import_projects_from_github.md (limited to 'doc/workflow') diff --git a/doc/workflow/README.md b/doc/workflow/README.md index 8ef51b50b9d..1fe63274c29 100644 --- a/doc/workflow/README.md +++ b/doc/workflow/README.md @@ -8,4 +8,5 @@ - [GitLab Flow](gitlab_flow.md) - [Notifications](notifications.md) - [Migrating from SVN to GitLab](migrating_from_svn.md) +- [Project importing from GitHub to GitLab](import_projects_from_github.md) - [Protected branches](protected_branches.md) diff --git a/doc/workflow/github_importer/importer.png b/doc/workflow/github_importer/importer.png new file mode 100644 index 00000000000..57636717571 Binary files /dev/null and b/doc/workflow/github_importer/importer.png differ diff --git a/doc/workflow/github_importer/new_project_page.png b/doc/workflow/github_importer/new_project_page.png new file mode 100644 index 00000000000..002f22d81d7 Binary files /dev/null and b/doc/workflow/github_importer/new_project_page.png differ diff --git a/doc/workflow/import_projects_from_github.md b/doc/workflow/import_projects_from_github.md new file mode 100644 index 00000000000..8644b4ffc73 --- /dev/null +++ b/doc/workflow/import_projects_from_github.md @@ -0,0 +1,13 @@ +# Project importing from GitHub to GitLab + +You can import your existing GitHub projects to GitLab. But keep in mind that it is possible only if +GitHub support is enabled on your GitLab instance. You can read more about GitHub support [here](http://doc.gitlab.com/ce/integration/github.html) +To get to the importer page you need to go to "New project" page. + +![New project page](github_importer/new_project_page.png) + +Click on the "Import project from GitHub" link and you will be redirected to GitHub for permission to access your projects. After accepting, you'll be automatically redirected to the importer. + +![Importer page](github_importer/importer.png) + +To import a project, you can simple click "Add". The importer will import your repository and issues. Once the importer is done, a new GitLab project will be created with your imported data. \ No newline at end of file -- cgit v1.2.1 From 061ac7923670083cf7237a32867b2f8ce86a1c83 Mon Sep 17 00:00:00 2001 From: Sytse Sijbrandij Date: Fri, 23 Jan 2015 11:18:10 -0800 Subject: Rename workflow to feature branch flow and add better desciption of workflow category. --- doc/workflow/README.md | 2 +- doc/workflow/workflow.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'doc/workflow') diff --git a/doc/workflow/README.md b/doc/workflow/README.md index 1fe63274c29..33176aaba44 100644 --- a/doc/workflow/README.md +++ b/doc/workflow/README.md @@ -1,6 +1,6 @@ # Workflow -- [Workflow](workflow.md) +- [Feature branch workflow](workflow.md) - [Project Features](project_features.md) - [Authorization for merge requests](authorization_for_merge_requests.md) - [Groups](groups.md) diff --git a/doc/workflow/workflow.md b/doc/workflow/workflow.md index ab29cfb670b..f70e41df842 100644 --- a/doc/workflow/workflow.md +++ b/doc/workflow/workflow.md @@ -1,4 +1,4 @@ -# Workflow +# Feature branch workflow 1. Clone project: -- cgit v1.2.1 From 7ba97ab4a53eba8d28d028a04e20e6ead1cd9f52 Mon Sep 17 00:00:00 2001 From: Dmitriy Zaporozhets Date: Mon, 2 Feb 2015 16:43:51 -0800 Subject: Web editor documnetation --- doc/workflow/README.md | 1 + doc/workflow/web_editor.md | 23 +++++++++++++++++++++++ doc/workflow/web_editor/edit_file.png | Bin 0 -> 99624 bytes doc/workflow/web_editor/empty_project.png | Bin 0 -> 122296 bytes doc/workflow/web_editor/new_file.png | Bin 0 -> 100516 bytes doc/workflow/web_editor/show_file.png | Bin 0 -> 111479 bytes 6 files changed, 24 insertions(+) create mode 100644 doc/workflow/web_editor.md create mode 100644 doc/workflow/web_editor/edit_file.png create mode 100644 doc/workflow/web_editor/empty_project.png create mode 100644 doc/workflow/web_editor/new_file.png create mode 100644 doc/workflow/web_editor/show_file.png (limited to 'doc/workflow') diff --git a/doc/workflow/README.md b/doc/workflow/README.md index 33176aaba44..3c0007d8198 100644 --- a/doc/workflow/README.md +++ b/doc/workflow/README.md @@ -10,3 +10,4 @@ - [Migrating from SVN to GitLab](migrating_from_svn.md) - [Project importing from GitHub to GitLab](import_projects_from_github.md) - [Protected branches](protected_branches.md) +- [Web Editor](web_editor.md) diff --git a/doc/workflow/web_editor.md b/doc/workflow/web_editor.md new file mode 100644 index 00000000000..c83715deff7 --- /dev/null +++ b/doc/workflow/web_editor.md @@ -0,0 +1,23 @@ +# GitLab Web Editor + +In GitLab you can create new files and edit existing one using our web editor. +Its really useful if you dont have access to command line or you want to make a quick small fix. +You can access to web editor in several ways depends on context. +Lets start from newly created project. +Click on `Add a file` button to start web editor for creating first file. + +![web editor 1](web_editor/empty_project.png) + +Fill in file name, content, commit message and press commit button. +After this file will be saved to repository. + +![web editor 2](web_editor/new_file.png) + +You can edit any text file in repository by pressing edit button when browsing file. + +![web editor 3](web_editor/show_file.png) + +Edit of file is pretty same as creating new file. +Except you can see preview of your changes to file in separate tab + +![web editor 3](web_editor/edit_file.png) diff --git a/doc/workflow/web_editor/edit_file.png b/doc/workflow/web_editor/edit_file.png new file mode 100644 index 00000000000..1522c50b62f Binary files /dev/null and b/doc/workflow/web_editor/edit_file.png differ diff --git a/doc/workflow/web_editor/empty_project.png b/doc/workflow/web_editor/empty_project.png new file mode 100644 index 00000000000..6a049f6beaf Binary files /dev/null and b/doc/workflow/web_editor/empty_project.png differ diff --git a/doc/workflow/web_editor/new_file.png b/doc/workflow/web_editor/new_file.png new file mode 100644 index 00000000000..80941f37cea Binary files /dev/null and b/doc/workflow/web_editor/new_file.png differ diff --git a/doc/workflow/web_editor/show_file.png b/doc/workflow/web_editor/show_file.png new file mode 100644 index 00000000000..9cafcb55109 Binary files /dev/null and b/doc/workflow/web_editor/show_file.png differ -- cgit v1.2.1 From 68fbf1423fddcb7d49e408d05105ca6911e91122 Mon Sep 17 00:00:00 2001 From: Job van der Voort Date: Tue, 3 Feb 2015 11:05:20 -0800 Subject: improve english documentation --- doc/workflow/web_editor.md | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) (limited to 'doc/workflow') diff --git a/doc/workflow/web_editor.md b/doc/workflow/web_editor.md index c83715deff7..bcadf5e8c0d 100644 --- a/doc/workflow/web_editor.md +++ b/doc/workflow/web_editor.md @@ -1,23 +1,26 @@ # GitLab Web Editor -In GitLab you can create new files and edit existing one using our web editor. -Its really useful if you dont have access to command line or you want to make a quick small fix. -You can access to web editor in several ways depends on context. -Lets start from newly created project. -Click on `Add a file` button to start web editor for creating first file. +In GitLab you can create new files and edit existing files using our web editor. +This is especially useful if you don't have access to a command line or you just want to do a quick fix. +You can easily access the web editor, depending on the context. +Let's start from newly created project. + +Click on `Add a file` +to create the first file and open it in the web editor. ![web editor 1](web_editor/empty_project.png) -Fill in file name, content, commit message and press commit button. -After this file will be saved to repository. +Fill in a file name, some content, a commit message and press the commit button. +The file will be saved to the repository. ![web editor 2](web_editor/new_file.png) -You can edit any text file in repository by pressing edit button when browsing file. +You can edit any text file in a repository by pressing the edit button, when +viewing the file. ![web editor 3](web_editor/show_file.png) -Edit of file is pretty same as creating new file. -Except you can see preview of your changes to file in separate tab +Editing a file is almost the same as creating a new file, +with as addition the ability to preview your changes in a separate tab. ![web editor 3](web_editor/edit_file.png) -- cgit v1.2.1 From ad6c372eeee5d112ad199dd4e487df584976445d Mon Sep 17 00:00:00 2001 From: Ewan Edwards Date: Tue, 3 Feb 2015 15:18:40 -0800 Subject: Fix a number of discovered typos, capitalization of developer and product names, plus a couple of instances of bad Markdown markup. --- doc/workflow/gitlab_flow.md | 8 ++++---- doc/workflow/migrating_from_svn.md | 2 +- doc/workflow/notifications.md | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) (limited to 'doc/workflow') diff --git a/doc/workflow/gitlab_flow.md b/doc/workflow/gitlab_flow.md index 1dbff60cbfd..0e87dc74217 100644 --- a/doc/workflow/gitlab_flow.md +++ b/doc/workflow/gitlab_flow.md @@ -43,7 +43,7 @@ Since most tools automatically make the master branch the default one and displa The second problem of git flow is the complexity introduced by the hotfix and release branches. These branches can be a good idea for some organizations but are overkill for the vast majority of them. Nowadays most organizations practice continuous delivery which means that your default branch can be deployed. -This means that hotfixed and release branches can be prevented including all the ceremony they introduce. +This means that hotfix and release branches can be prevented including all the ceremony they introduce. An example of this ceremony is the merging back of release branches. Though specialized tools do exist to solve this, they require documentation and add complexity. Frequently developers make a mistake and for example changes are only merged into master and not into the develop branch. @@ -95,12 +95,12 @@ An 'extreme' version of environment branches are setting up an environment for e ## Release branches with GitLab flow -![Master and multiple release branches that vary in length with cherrypicks from master](release_branches.png) +![Master and multiple release branches that vary in length with cherry-picks from master](release_branches.png) Only in case you need to release software to the outside world you need to work with release branches. In this case, each branch contains a minor version (2-3-stable, 2-4-stable, etc.). The stable branch uses master as a starting point and is created as late as possible. -By branching as late as possible you minimize the time you have to apply bugfixes to multiple branches. +By branching as late as possible you minimize the time you have to apply bug fixes to multiple branches. After a release branch is announced, only serious bug fixes are included in the release branch. If possible these bug fixes are first merged into master and then cherry-picked into the release branch. This way you can't forget to cherry-pick them into master and encounter the same bug on subsequent releases. @@ -177,7 +177,7 @@ In GitLab this creates a comment in the issue that the merge requests mentions t And the merge request shows the linked issues. These issues are closed once code is merged into the default branch. -If you only want to make the reference without closing the issue you can also just mention it: "Ducktyping is preferred. #12". +If you only want to make the reference without closing the issue you can also just mention it: "Duck typing is preferred. #12". If you have an issue that spans across multiple repositories, the best thing is to create an issue for each repository and link all issues to a parent issue. diff --git a/doc/workflow/migrating_from_svn.md b/doc/workflow/migrating_from_svn.md index 207e3641802..485db4834e9 100644 --- a/doc/workflow/migrating_from_svn.md +++ b/doc/workflow/migrating_from_svn.md @@ -3,7 +3,7 @@ SVN stands for Subversion and is a version control system (VCS). Git is a distributed version control system. -There are some major differences between the two, for more information consult your favourite search engine. +There are some major differences between the two, for more information consult your favorite search engine. Git has tools for migrating SVN repositories to git, namely `git svn`. You can read more about this at [git documentation pages](http://git-scm.com/book/en/Git-and-Other-Systems-Git-and-Subversion). diff --git a/doc/workflow/notifications.md b/doc/workflow/notifications.md index 3c3ce162df5..17215de677e 100644 --- a/doc/workflow/notifications.md +++ b/doc/workflow/notifications.md @@ -24,14 +24,14 @@ Each of these settings have levels of notification: #### Global Settings Global Settings are at the bottom of the hierarchy. -Any setting set here will be overriden by a setting at the group or a project level. +Any setting set here will be overridden by a setting at the group or a project level. Group or Project settings can use `global` notification setting which will then use anything that is set at Global Settings. #### Group Settings -Group Settings are taking presedence over Global Settings but are on a level below Project Settings. +Group Settings are taking precedence over Global Settings but are on a level below Project Settings. This means that you can set a different level of notifications per group while still being able to have a finer level setting per project. Organization like this is suitable for users that belong to different groups but don't have the @@ -39,7 +39,7 @@ same need for being notified for every group they are member of. #### Project Settings -Project Settings are at the top level and any setting placed at this level will take presedence of any +Project Settings are at the top level and any setting placed at this level will take precedence of any other setting. This is suitable for users that have different needs for notifications per project basis. -- cgit v1.2.1 From 78124d97836ebdfbb45c5567b9f2775889fd9718 Mon Sep 17 00:00:00 2001 From: Valery Sizov Date: Fri, 13 Feb 2015 20:13:47 +0200 Subject: GitLab.com importer: documentation --- doc/workflow/README.md | 1 + doc/workflow/gitlab_importer/importer.png | Bin 0 -> 40778 bytes doc/workflow/gitlab_importer/new_project_page.png | Bin 0 -> 72663 bytes doc/workflow/import_projects_from_gitlab_com.md | 18 ++++++++++++++++++ 4 files changed, 19 insertions(+) create mode 100644 doc/workflow/gitlab_importer/importer.png create mode 100644 doc/workflow/gitlab_importer/new_project_page.png create mode 100644 doc/workflow/import_projects_from_gitlab_com.md (limited to 'doc/workflow') diff --git a/doc/workflow/README.md b/doc/workflow/README.md index 3c0007d8198..6e70235f5b8 100644 --- a/doc/workflow/README.md +++ b/doc/workflow/README.md @@ -9,5 +9,6 @@ - [Notifications](notifications.md) - [Migrating from SVN to GitLab](migrating_from_svn.md) - [Project importing from GitHub to GitLab](import_projects_from_github.md) +- [Project importing from GitLab.com to your private GitLab instance](import_projects_from_gitlab_com.md) - [Protected branches](protected_branches.md) - [Web Editor](web_editor.md) diff --git a/doc/workflow/gitlab_importer/importer.png b/doc/workflow/gitlab_importer/importer.png new file mode 100644 index 00000000000..d2a286d8cac Binary files /dev/null and b/doc/workflow/gitlab_importer/importer.png differ diff --git a/doc/workflow/gitlab_importer/new_project_page.png b/doc/workflow/gitlab_importer/new_project_page.png new file mode 100644 index 00000000000..5e239208e1e Binary files /dev/null and b/doc/workflow/gitlab_importer/new_project_page.png differ diff --git a/doc/workflow/import_projects_from_gitlab_com.md b/doc/workflow/import_projects_from_gitlab_com.md new file mode 100644 index 00000000000..f4c4e955d46 --- /dev/null +++ b/doc/workflow/import_projects_from_gitlab_com.md @@ -0,0 +1,18 @@ +# Project importing from GitLab.com to your private GitLab instance + +You can import your existing GitLab.com projects to your GitLab instance. But keep in mind that it is possible only if +GitLab support is enabled on your GitLab instance. +You can read more about Gitlab support [here](http://doc.gitlab.com/ce/integration/gitlab.html) +To get to the importer page you need to go to "New project" page. + +![New project page](gitlab_importer/new_project_page.png) + +Click on the "Import projects from Gitlab.com" link and you will be redirected to GitLab.com +for permission to access your projects. After accepting, you'll be automatically redirected to the importer. + + +![Importer page](gitlab_importer/importer.png) + + +To import a project, you can simple click "Import". The importer will import your repository and issues. +Once the importer is done, a new GitLab project will be created with your imported data. \ No newline at end of file -- cgit v1.2.1 From 53e404144c8ce9f602ec1e3a642d5d3971dc8217 Mon Sep 17 00:00:00 2001 From: Valery Sizov Date: Tue, 24 Feb 2015 20:24:30 +0200 Subject: changelog && documentation --- doc/workflow/web_editor.md | 4 ++-- doc/workflow/web_editor/edit_file.png | Bin 99624 -> 89039 bytes doc/workflow/web_editor/new_file.png | Bin 100516 -> 85526 bytes 3 files changed, 2 insertions(+), 2 deletions(-) (limited to 'doc/workflow') diff --git a/doc/workflow/web_editor.md b/doc/workflow/web_editor.md index bcadf5e8c0d..7fc8f96b9ec 100644 --- a/doc/workflow/web_editor.md +++ b/doc/workflow/web_editor.md @@ -10,7 +10,7 @@ to create the first file and open it in the web editor. ![web editor 1](web_editor/empty_project.png) -Fill in a file name, some content, a commit message and press the commit button. +Fill in a file name, some content, a commit message, branch name and press the commit button. The file will be saved to the repository. ![web editor 2](web_editor/new_file.png) @@ -21,6 +21,6 @@ viewing the file. ![web editor 3](web_editor/show_file.png) Editing a file is almost the same as creating a new file, -with as addition the ability to preview your changes in a separate tab. +with as addition the ability to preview your changes in a separate tab. Also you can save your change to another branch by filling out field `branch` ![web editor 3](web_editor/edit_file.png) diff --git a/doc/workflow/web_editor/edit_file.png b/doc/workflow/web_editor/edit_file.png index 1522c50b62f..f480c69ac3e 100644 Binary files a/doc/workflow/web_editor/edit_file.png and b/doc/workflow/web_editor/edit_file.png differ diff --git a/doc/workflow/web_editor/new_file.png b/doc/workflow/web_editor/new_file.png index 80941f37cea..55ebd9e0257 100644 Binary files a/doc/workflow/web_editor/new_file.png and b/doc/workflow/web_editor/new_file.png differ -- cgit v1.2.1