Continuous Integration in conjunction with DVCS - how?

Question

git

Given:
* DVCS - Git
* CI server - Hudson
* We use the GitFlow
branching model Now the question is - what events in the origin repository and what should CI collect?
Share your experience, please.
It is clear that any commit in master must build a release.
Most likely, a commit in develop should also compile the build, run the tests and deploy to the demo server.
But with feature branches there are misunderstandings. We need CI to integrate often. That is, ideally, for each commit in feature-*, you need to merge with develop and, if successful, compile and test the build. Do I need to commit the changes back to develop on origin upon success (like hudson can do this)?
If yes, then the risk of breaking develop increases. In any case, it contains unfinished features. If not, then integration with the work of other developers/teams is postponed until the completion of the feature and its final merge in origin/develop. And by this time, conflicts can accumulate.
And at what point do we do code review?

Answer 1

I don’t know, we make commits in develop only by hand and only after manual testing. Yes, hudson can do post-build push, but successful test runs do not mean that the program works absolutely correctly.

Answer 2

a feature branch is generally speaking a thing for local development by a developer. Sometimes it is necessary to share with another developer the code from this branch, then, as a necessary evil, this branch ends up in the central repository of your team. But generally speaking, it does not exist for the rest of the world. And the functionality for the world begins to exist only when the branch is merged into develop, and it itself is already nailed.
So, based on the above, CI collects only develop and master. There are no other brunches for him.
The solution to the difficulties when merging branches to development after a long period is to periodically backport changes from development to branch so that the branch is always up-to-date with changes in development.
The review code is done when merging branches in development, i.e. when you can see the changes between the result git merge --no-ff --no-commitand the develop baseline.