Team work, I work on the same files. But since I implement different features, I need to create for each individual pull request. The algorithm is as follows: I update the master, create my branch (feature1), make a feature, create a pull request, wait for approval, and merge my feature1 into a master.

But since approval is taking a long time, and I don’t want to waste time, how should I do it right? Before PR is not yet approved, I create a new branch feature2, not from the wizard, but from feature1. Similarly, I work, as a result, I push changes to the server. Now create a new PR, regardless of the approval of the first? Or do you have to wait for the approval of the first one, merge it into the master, merge the master into the second branch, and then create a new PR on feature2? Or you can create multiple PRs at once?

    2 answers 2

    That's right - each feature has its own branch. There will be nothing terrible if you create 10 pull requests, but all of them must be taken away from the master (or develop - see the company's policy).

    It is possible to branch a branch from a branch, but only if the new feature depends on the previous one and on the other way. But it should be understood that the verifier may not be aware of this and will watch the second pull request, which will include changes from the first. And it may well be that the first and not needed. That is, the reviewer will do extra unnecessary work.

    Summing up:

    • one feature - one branch from the master (developer), one pull request.
    • The amount of pull request is limited by common sense.
    • You can create a branch from a branch, but only if it is related functionality and in this case it is better to wait for the approval of the first pull request, and only then do the next one, possibly rebounding the branch with the next feature of the new wizard (to simplify the verifier).

    PS in git do not need to be afraid to create a lot of branches.

    • +1 Don't forget to delete the topic branch after the merge. - 0andriy
    • Just about double work for the verifier. Suppose (and I have just that) that I create branches from one another. master-> feature1-> feature2-> feature3, etc. Will there be double work for the verifier, if I wait for the PR1 PR1 (feature1), I’m merging then this branch in the master, then I’m merging the master in feature 2 and then creating PR2, etc. on a chain. - Sergey Gernichenko
    • No, it should not. But in any case, I recommend trying it on a separate repository and see. Very useful. - KoVadim

    Yes, there is no big problem

    While the guys review the feature branches, we go into it and do a rebase when we see that the new changes have flown into the master so as to prevent conflicts

    And the second branch is re-branded relative to the first one until it is squeezed. As its other line is re-branded to master and the commits of the first branch disappear from the second and there will be pure PR

    Of course it’s best not to allow this, it’s not very convenient yourself :(

    How advice yet

    • We use PR Labels, for example, WIP (working in progress) on our second branch this will be an indicator of the fact that you do not need to merge

    • Use Review and tag people who are watching a thread.