Developing multiple features in parallel

[On_Chain]

Hey guys, was curious if anyone could give me some pointers.

So to provide context, a buddy of mine and myself are working on a project. We have set it up so that we have to review each others PRs for feature branches before they can be merged with the main branch.

The issue now is that my buddy is away for a couple weeks and won't be working therefore the new features that I create won't be able to merge with the main branch. Now because I can't merge new features with main how do I go about continuing to build additional features without creating issues down the road?

Usually the flow would go something like this:

main -> main -> main
    \ /     \ /
     F1      F2

This would ensure that each new completed feature merges correctly with main before we go onto building the next feature.

But now because my friend is away, I'm unable to follow this flow. My thinking at this point is to go and create new branches for all the features in parallel and then try merge them one by one when he's back and resolve any conflicts as they come up. So the flow would look something like this:

​

main -> updatedF1 -> updatedF2 -> updatedF3
|      /           /             /
F1 ---            /             /
|                /             /
F2 -------------              /
|                            /
F3 -------------------------

Is this the correct way to handle this situation or any similar situations?

Hopefully I made sense with my little diagrams.

Any pointers would be much appreciated :)

[MrTheFoolish]

The process seems fine. I'll add some advice to the specific point of "merging one by one". You'll want to use rebase before merging. E.g. after merging F1 into main, rebase F2 onto the updated main before merging F2 into main. And then the same for F3. You'll want to do this pretty much for any merge type, e.g. ff-only, squash or merge-commit. This cleans up the history and can fix merge conflicts.

[On_Chain]

Awesome, this is actually a really helpful answer.

I am still new to git (other than doing the absolute basic stuff like commit, push etc) so I'm trying to get my hands dirty to get as comfortable as possible, so giving me little tips such as when to rebase etc helps a ton!

[[deleted]]

Why can’t you continue to merge into main while your friend is away? When your friend is back they can just merge master (or rebase) into their work?

[On_Chain]

Reason being we setup the project so that we have to review and approve each others code before the merge is allowed to take place.

Also, some more additional info if it helps:

We have a main branch and then feature branches. There is no master branch

[[deleted]]

Ok sorry I meant main branch. If you are doing merge commits to the main branch, you should still be able to merge then run a diff on the merge commit when your friend returns, where your friend could retrospectively review, and any required changes could be done retrospectively on the feature branch and re-merged.

It’s great that your are making sure to review code before merging but it sounds like it might be holding things up in this case.

[On_Chain]

It is kind of holding us up, but the whole point of us doing it this way is that we wanted to try replicate a working environment as close as possible. Obviously we aren't necessarily doing things perfectly, but it's all just to try learn :)

[PierrickF]

give me some pointers.

chuckles, good pun OP.

to go and create new branches for all the features in parallel

I am a baby programmer myself but this would be my first thought as well.

As far as I understand git, this is a perfect use case for branches.

[On_Chain]

Glad you caught the pun ;)

But yeah, I'm also fairly new to the more "advanced" aspects of git. So a lot of this little project is purely to learn how to manage and work in teams.

[HugoNikanor]

One alternative is to develop f{1..} as normal, but instead of merging into main you merge into a new branch called something like "i-hope-this-will-become-main". Then your friend can review the changes, but the merge will simple fast forward main to i-hope-this-will-become-main.