Re: Process clarification regarding branches, merge requests

[Aaron Hill]

On 2021-11-15 10:44 am, Jean Abou Samra wrote:
> Le 15/11/2021 à 19:00, Aaron Hill a écrit :
========================================================================
> > I should state that I only have experience with GitHub, so I might
> > mix up terminology when trying to map things to GitLab.
> >
> > Is there a preference whether development branches should be created
> > on the repository itself versus a forked copy?  What I am used to on
> > GitHub is working from my own fork, creating branches as needed, and
> > then submitting a pull request that can be merged when validated and
> > approved.  I see some merge requests for the project are coming from
> > branches within the origin repository.  Is this a policy thing or
> > something where GitLab just fundamentally works differently than
> > GitHub?
>
> People without developer permissions cannot push on the
> shared repository. Therefore, they always have to open
> merge requests from a fork. Once you have been granted
> developer priviledges, you can create branches on 'origin'
> and you have the choice. A branch on the shared repository
> means it's a little easier for others to check it out
> (though it's not hard with branches on forks; GitLab
> helpfully displays pastable commands when you click
> 'Check out branch' in a merge request).

Makes sense.  I would stick to working from my fork, more because it 
feels more familiar.


> On the other
> hand, you should not forget to delete the branch if
> the merge request happens to be closed.

GitHub provides a handy "delete branch" button when your PR is merged, 
but it's not hard to remember to clean things up.  I never like stale 
branches hanging around anyway.


> By convention,
> branches pushed to the main repository start with 'dev/'.

It looks like some folks even go as far as prefixing 'dev/<username>/'.  
Is this again just personal preference?


-- Aaron Hill