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?
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.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.
I think that you can add a WIP prefix to the MR title to prevent the maintainers from accidentally merging the branch prematurely.
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?