1

I have done a lot of research but still kind of new and confused. Could not wrap my head around this or it might be that I read a lot and now I am really confused.

Scenario Example:

My friend adds me as a collaborator on a project and i have to fulfill 3 requirements. Write a function A , B and C in a same file which is abc.txt. I make a new branch off of master branch. Write my function A in abc.txt and push to my branch. I initiate a pull request and wait for the review.

Now here is where I am getting confused. I need to work on the same file and need to write my function B and C and have them reviewed too so what is the optimum way to do it?

One is to keep making change to the same file which has the PR pending or checkout a new branch ?

indexOutOfBounds
  • 541
  • 7
  • 27

2 Answers2

1

If A, B, and C are all independent, then I think it makes sense to checkout a new branch, implement A, submit a PR for this, then go back to the master branch. Then checkout a new branch for B, submit a second PR for this, and then return to the original branch and repeat again for C. So at the end of this, before any of your PRs are reviewed, your tree might look like

--------o master
        |---------feature_A_branch
        |---------feature_B_branch
        |---------feature_C_branch

This lets you create further commits in each branch to address PR suggestions and then when each PR is accepted, you can squash-merge it back into master so that you'd have exactly one commit in master for each of feature A,B, and C.

Of course, this assumes that A, B, and C don't depend on each other at all

Editing to add something about when A, B, and C share code:

If A, B, and C depend on some shared code S, then you might modify the above so that instead of checking out master after finishing A and making a new branch there, you check out to S while the branch with {S,A} is still in PR. This would look something like

---o master
   |
   |----S---feature_A (with commit for the common shared code)
        |---feature_B
        |---feature_C

Then, when whichever of A, B, or C pass PR first (lets assume B for concreteness), you'd merge feature_B back into master, which would also bring the changes in S to master as well. Now, you could rebase feature_A and feature_C on master (which post-merge has the changes in S) so then feature_A only has changes for A and feature_C only has changes for C. Post rebase and merge, the tree might look like:

---o---S---B (master)
           |----feature_A
           |----feature_C
hjobrien
  • 141
  • 1
  • 10
  • So let's say I am given a base project. I pull that. Write whole lot of code to make my fun A work , push and send it for review. The same code i wrote for A is also needed to write fun B but of course with different usage. Would not we have to rewrite the base code we wrote for A in all separate branches? – indexOutOfBounds Jun 29 '20 at 22:08
  • So what you're describing is a situation where A, B, and C are not independent, because they share that same base code. In that case, you're right that my proposed solution would involve rewriting the base code, which is why I specified that this solution is for independent features. I'll update it with a suggestion for the dependent case – hjobrien Jun 29 '20 at 22:35
  • Firstly, if i got you right then you mean that initially when we checked out from master to branch S where we wrote all of our base code an fun A. We later on checkout from branch S to another or ..? i lost it there – indexOutOfBounds Jun 29 '20 at 22:56
  • Yeah sorry to clarify, changes S are initially made on branch `feature_A` in a separate commit. Then, we checkout the commit with changes S and create a new branch `feature_B` with this commit as the base commit (So the commit with changes S is the first common ancestor of `feature_A` and `feature_B`). You'd then do exactly the same thing for C that we did for B – hjobrien Jun 29 '20 at 23:38
0

If your further work depends on function A then, make a new branch from your old branch and continue your work once done make a new pull request.

Mantas A.
  • 11
  • 3
  • Yes i tried that before but instead of being a separate pull request, it goes into the same PR which we did before. If this is the case why not add more commits to the same one – indexOutOfBounds Jun 29 '20 at 22:33