[Top][All Lists]

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

Re: Process clarification regarding branches, merge requests

From: Jean Abou Samra
Subject: Re: Process clarification regarding branches, merge requests
Date: Mon, 15 Nov 2021 19:44:23 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1

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). On the other
hand, you should not forget to delete the branch if
the merge request happens to be closed. By convention,
branches pushed to the main repository start with 'dev/'.


reply via email to

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