2

not sure if this is the right forum. But I'm stuck at how to create multiple pull requests for a single file that is appended. My specific use case is Cucumber feature files. One writes a couple of scenarios and wants to put them at the bottom of one file. But for review purposes it is better to have multiple PRs. If multiple PRs are submitted, then first merge PR makes the other PRs into a conflict.

e.g.

my.feature
Feature: My Feature
  ...

  Scenario: new 1
    ...

  Scenario: new 2
    ...

If one files scenario "new 1" as a separate pull, and then a new pull of the base branch with scenario "new 2", then merging either of those will result in the other one conflicting.

Update: similar questions without github specifics (probably not possible presently):

Community
  • 1
  • 1
akostadinov
  • 17,364
  • 6
  • 77
  • 85
  • It's mostly depends on your git workflow. If you have one *branch per feature* you will certainly avoid this issue. – felixyadomi May 16 '16 at 15:26
  • @FelixYadomi, you need to have a branch per pull request, you can't have multiple pulls from one branch. This is not related to the issue that in fact git merge would fail if two pulls try to append to the same file. Can git or github be smart enough to append to a file from different PRs. – akostadinov May 16 '16 at 16:20
  • 1
    A Feature files should map 1-1 to a story. Is your problem that multiple people want to work on different scenarios concurrently? If the Scenarios are grouped in a single feature file and people work on **different** scenarios in that single Feature file then there shouldn't be a need to resolve merge *conflicts*. It is unreasonable to have two people concurrently work on the same scenario; don't do it. – MikeJRamsey56 May 16 '16 at 22:13
  • @MikeJRamsey56, I asked mainly about one person appending multiple scenarios to the same feature file. I don't see why multiple people can't append to same feature file if testing the feature requires some different skills or just that this is how tasks are split. For review it is usually preferable to have work split in pieces so issue in one piece doesn't block other pieces that are just fine. – akostadinov May 17 '16 at 14:02
  • One person shouldn't have any merge problems. :-) By append do you mean edit and add? – MikeJRamsey56 May 18 '16 at 00:31
  • @MikeJRamsey56, if you add to the same file in multiple PRs/branches, then you have. wrt append - yes - edit and add lines. – akostadinov May 18 '16 at 19:15
  • Are you changing the same scenario in multiple branches? That would cause an eventual merge conflict. I wouldn't break the work up that way. Divide and conquer works only when the division leaves pieces that are relatively independent of each other. Highly dependent pieces should be grouped and worked on together. – MikeJRamsey56 May 18 '16 at 21:43
  • @MikeJRamsey56 I said append multiple scenarios to same file. e.g. add scenario to end in one branch. Add another scenario at end in another branch. File 2 pull requests. – akostadinov May 19 '16 at 06:15
  • If the scenarios are different then git should merge them cleanly on its own without your intervention when you merge the branches. – MikeJRamsey56 May 23 '16 at 03:23
  • @MikeJRamsey56, What makes you think so? I bet you didn't try. Here's an example: https://github.com/akostadinov/testcuke/pull/1 and https://github.com/akostadinov/testcuke/pull/2 ; I merged first one and then second one is in conflict. – akostadinov May 23 '16 at 22:37
  • You are changing the same Given/When/Then statements. If the G/W/T statements are shared between scenarios then you will have merge conflicts. If they are not shared between scenarios then you will not have merge conflicts. Group the G/W/T statements in different files. Divide them up to maximize internal cohesion and to minimize external cohesion. The smaller the groupings (and more files) the less likely you are to have merge conflicts. Look back at what I said about divide and conquer. Choose wisely. – MikeJRamsey56 May 24 '16 at 03:51
  • @MikeJRamsey56, I think you're just not reading. I'm strictly appending lines in both PRs. Nothing is modified. – akostadinov May 24 '16 at 13:19
  • Your example showed G/W/T in step defs hence my response. Take a look at the answer [here](http://stackoverflow.com/questions/13263902/git-merge-keep-both). – MikeJRamsey56 May 25 '16 at 02:48
  • @MikeJRamsey56, ok, thank you, that now is something. I have to try if it's gonna work in github though as I just today had a PR that showed conflicts in github but rebased cleanly with 3-way merge locally. If you write an answer I'll vote it up anyway. – akostadinov May 25 '16 at 12:12

0 Answers0