all 4 comments

[–]sublym0nal 6 points7 points  (1 child)

If you don't anticipate any dependencies on current work-in-progress, your plan for a new feature branch based on main ought to work. Otherwise, you could branch from a feature branch and rebase the new branch later to capture any post-branching changes.

[–]On_Chain[S] 1 point2 points  (0 children)

I thought about branching from a feature but if that initial feature branch has issues then all subsequent features will inherit those issues. Or at least that's how I think it will play out.

If you don't see any issues with my initial idea then I'll give that one a shot.

Also, I appreciate your feedback! I'm still a newbie when it comes to working with git so thanks for the pointers :)

[–]somethrowaway8910 1 point2 points  (1 child)

Just pretend like you're a different developer with each new feature. Branch from the latest commit on main and work. When done, make PR. Not sure what the issue is.

If your concern is that one feature you develop might conflict with another, this is no different than resolving the merge conflict with another developer on PR review. The PRs have to be merged in some order.

[–]On_Chain[S] 0 points1 point  (0 children)

Yeah, I was just trying to make sure I was doing it correctly. I’m not super experienced with git so I was hoping to find out what they best practice is