0

When I have to make a series of pull requests that stack on top of each other (i.e., each subsequent commit is independent on the previous one), I just work on each one in serial and then push the commits.

I also often work with situations where the commits are non-related, and in this situation, I wonder what the proper etiquette should be. What I have been doing is essentially working on one commit, pushing it, then resetting my local branch to the remote master branch before working on the second commit, and so on. Is this the recommended route when the commits aren't related to one another?

user5965026
  • 465
  • 5
  • 16

3 Answers3

1

From what I've read, most people say that there is no absolutely correct system. But you should take advantage of the flexibility that git allows to adapt it to the development needs.

There are different circumstances that make the optimal method vary, such as the number of developers working on the project, the type of project, etc.

In my opinion, the ideal case is never to develop on the master/main branch, but instead create a branch for each related task to have the different commits of unrelated tasks grouped together.

In the master/main branch there should only be published commits corresponding to version jumps, and these version jumps occur when merging/committing the development branches

Check this link for extended info: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Diego Martínez
  • 41
  • 6
1

It is usual to create new branches from the 'main' (also 'master') and after code review, testing, etc. branch (with any number of new commits) to merge request into 'main'.

Once the 'main' is updated, you will rebase any branch in progress.

Reset is especially useful if something goes wrong and then you add cherry-pick commit from any branch

OtiK.cz
  • 95
  • 4
1

Your team should strive to reviewing PRs quickly so that there's no build up. Typically you shouldn't have more than 1 PR open at a time.

In case you do want to work on a completely different feature while your PR is being reviewed, you're right that you should base it off the trunk. Otherwise if you create yet another commit on top of your PR, it's going to be more challenging to update that PR:

  1. You'll have to either temporarily remove your unrelated commit, update PR and then cherry-pick the unrelated commit back.
  2. Or you'll have to commit it on top of unrelated commit, then run git rebase -i ... to change the order

Both options are more complicated than just committing unrelated commit based on the trunk.

Stanislav Bashkyrtsev
  • 14,470
  • 7
  • 42
  • 45