Using Pull Requests with different commits

Question

For a new project we try to set up the development process and the intention is to have a simple, pragmatic process. We use Atlassian Stash with Git in our company.

We came up with the following proposal:

In the central repo exist two branches development and production. All development takes place in the development branch and all commits are done in this branch.

If a developer has finished a feature, he creates a pull request so the new feature can be reviewed and merged into production, where all the final testing and deployment takes place.

In today's discussion arised the question, if it's possible to create a pull request for one feature, if different developers develop different features in one branch.

So the commits would look like this:

commit 1: feature 1

commit 2: feature 1

commit 3: feature 2

commit 4: feature 1

commit 5: feature 3

commit 6: feature 4

commit 7: feature 1

Is it even possible to have a pull request, which incorporates the commits 1, 2, 4 and 7 without the commits in between?

I'm aware of the concept "one branch for each feature", but for the moment we try to set up a simple process without too many branches, because the developers come from SVN and don't have much experience with Git.

Suggestions welcome!

EDIT: I googled around a little more and probably the GitHub flow strategy might be what we are looking for.

Answer 1

As Juan Carlos says, the most obvious way to do it would be by cherry picking into separate branches. This may or may not be trivial, depending on how much the commits of the different features are based on each other.

You could also use --no-commit to merge 'interactively' multiple times - 1, 2 - but that's quite tricky.

Anyway, you said 'Suggestions Welcome', so...

for the moment we try to set up a simple process without too many branches

What you've described may seem conceptually simple to visualise, but I don't think you'll find it a practical way of working.

Let's take the scenario where features 1, 2, 3, and 4 are entirely unrelated. By developing them all on one branch, you don't make the merging much easier, but you force developers to constantly rebase as they constantly find the head of their development branch is behind the one they want to push to, due to other developers making commits.

Now let's take the scenario where the four features are separate from a user point of view, but interact somewhat within the code. What if features 2 and 3 work fine, 1 is starting to become much harder than you thought and you want to push that back to the next release, and you decide that 4 was a mistake. How are you going to isolate 2 and 3?

If a developer has finished a feature, he creates a pull request so the new feature can be reviewed and merged into production, where all the final testing and deployment takes place.

I don't see how that's always going to be possible - what if he has finished (2), but he has based some of his commits on an unfinished feature (1)? He's going to drag half of an unfinished feature in with his pull request.

There may also be difficulty in responding to review, as once the review has finished, three other developers may have based their work on yours anyway.

Answer 2

The Pull request is for one branch to be merged into another. What you are asking is not possible. What would happen to the other commits?

What you do here is simple to cherry pick your commits and create another branch, which you will merge into your main. You'll have the rest of your commits on your old branch.

On a side note, I would suggest you reconsider your branching strategy. It is way easier to review features individually than in a bunch, plus that way you'll have functionality in your main branch much faster. And you will avoid issues like the one in this question.