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

Git

3224 readers
8 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 2 years ago
MODERATORS
 

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 (3 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.

[–] GarytheSnail 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 (2 replies)
load more comments (2 replies)