Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • vlbi_monitor vlbi_monitor
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 26
    • Issues 26
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • radiolab
  • vlbi_monitorvlbi_monitor
  • Issues
  • #9

Closed
Open
Created Apr 11, 2016 by Harm Munk@harmmOwner

Set Gitlab development strategy

We need to establish a development strategy. Pim Schellart has proposed two alternatives:

  1. Each developer has one personal branch, say users/pschella, users/hmunk etc.) that we work on and push to. Then we send merge request to master via gitlab and assign one of the others to review and merge.

  2. We create a separate branch for each feature, preferably connected to an issue on the issue tracker (e.g. issue-42) and then send merge requests for those.

The second one has the advantage of having a single merge per issue and a good tracking between issues and code fixes. But it is a little more work as well.

Assignee
Assign to
Time tracking