What should be the git workflow to keep master's linear history?

Question

git

Tell me, please, the most correct git workflow that would preserve the linear history of master'a. Here's what I could come up with.

Rules:
1. You cannot commit to the master branch. You can only merge into it.
2. There are two roles in the development process: (1) simple developer and (2) coordinator.

Development process:
1. The developer creates a topic branch from the master branch.
2. Writes code in the topic branch.
3. Periodically performs merge from master to topic. At the same time, topic is already becoming non-linear, and rightly so.
4. Once he has finished developing the code in the topic, he tells the coordinator that the code is ready.
5. Coordinator performs code review in topic branch. If he finds errors, he informs the developer and he fixes them in the topic branch.
6. If the coordinator has found no errors in the topic branch, it rebases the topic on master, and then fast forwards the topic merge to master.
7. Notifies the developer that the merge is complete and the topic branch can be removed.

Benefits:
1. We keep the linear structure of the master branch.

Disadvantages:
1. After the rebase of the topic marriage by the coordinator, it becomes invalid for the developer. And I don't like it.

In general, the question is this. Is there a more correct development process that preserves the master's linear structure?

Answer 1

A couple of questions:

1. You cannot commit to the master branch. You can only merge into it.

If only the coordinator still works with the master, then what difference does it make how he will replenish it?

3. Periodically performs merge from master to topic. At the same time, topic is already becoming non-linear, and rightly so.

What for? Why shouldn't he rebase his own branch to the right place in the master or pull out the necessary commits from there via cherry-pick?
The ban on rebase before merging to upstream, for example in Linux, is due to the fact that the code must already be tested in the topic, and after the rebase it will have to be tested again. In addition, if there were conflicting changes in the master and in the topic, then it is better to fix them in one place - at the point of merge of the topic, than to spread them over different conflicting commits of the topic when it is rebase.

Answer 2

git add --al
git stash
git pull
git stash apply
git commit -am "comment"
git push
Commit to master only, no branches. For 2-3 people - that's it.

Answer 3

habrahabr.ru/post/147260/