this post was submitted on 18 Nov 2023
3 points (100.0% liked)

Git

2541 readers
10 users here now

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Resources

Rules

  1. Follow programming.dev rules
  2. Be excellent to each other, no hostility towards users for any reason
  3. No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

founded 1 year ago
MODERATORS
[email protected]
[email protected]
[email protected]
3
Branching and Merging question (lemmy.sdf.org)
submitted 1 year ago by [email protected] to c/[email protected]
5 comments fedilink hide all child comments
 

Hello,

I have only ever used git in very very basic way: commit, branch, merge request, that's pretty much it.

I have a use case where I pull the repository locally, branch (let's call it branch1), write some code, test it, commit, then create a merge request to master branch.

The merge request takes some time to be approved. During that time I would like to add more edits on top of those I submitted in the merge request. What would be the correct steps here?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 1 year ago (4 children)

A merge request isn't a git thing; It is an extension of some platforms. If you continue developing on the same branch as the mergerequest was issued for, github and gitlab will list your commits within the Merge Request once you have pushed them to your remote.

If you do not want this, you can simply branch off after issuing your merge request.

[–] [email protected] 1 points 1 year ago (2 children)

ok, so a "merge request" can be viewed as "merge of branch1 into master will happen at a time I cannot control".

Now, branch1 is checked out, if I do git switch -c branch2, it will start a new branch2 based on the last commit from branch1, right? I feel it's safer, since I don't know when branch1 will merge, server-side.

[–] [email protected] 2 points 1 year ago (1 children)

Exactly.

Depending on the upstream guidelines (check for a CONTRIBUTION file) you may open a MR with your initial development efforts. And reuse the branch until you have finished the feature. Then you request a review.

Or you may first mention your branch on a issue and only create the merge request once the entire feature is developed.

If you are developing another feature, use a dedicated branch.

In any case, the author merging may elect only specific portions of your change.

Also note that it is perfectly normal that a merge request will be open for months. So don't be discouraged. There may already be people profiting from your change. You just don't see it.

[–] [email protected] 1 points 1 year ago

I think that you can add a WIP prefix to the MR title to prevent the maintainers from accidentally merging the branch prematurely.

[–] [email protected] 1 points 1 year ago

If you have zero idea when but you assume it will be merged at some point, I think you've got the right idea.

Do you know the merge strategy of the remote? Is it fast forward only, merge commit, squash then merge commit?

load more comments (1 replies)