[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/'.
Best,
Jean
Re: Process clarification regarding branches, merge requests, Jonas Hahnfeld, 2021/11/16