[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Process clarification regarding branches, merge requests

From: Aaron Hill
Subject: Re: Process clarification regarding branches, merge requests
Date: Mon, 15 Nov 2021 11:05:15 -0800
User-agent: Roundcube Webmail/1.4.9

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]