CODEWITHSUNDEEP
gitgerrit
live_for_this
live_for_this

Reputation: 51

Gerrit workflow for keeping two branches in sync

My team started to work on project that is using gerrit code review. We have our own feature branch and work is going to take some time so we would like to keep up with changes in development branch.

We should regularly fetch changes and merge them with our own work. After each merge there would be many new commits that were already reviewed on development branch. We would like preserve history and avoid squashing commits. My question is how are we supposed to push all that changes to our branch.

Pushing for review doesn't make much sense because all that changes are already reviewed. Is pushing directly good choice in this situation? What is the correct workflow?

Upvotes: 0

Views: 1369

Answers (2)

user3154911
user3154911

Reputation:

With gerrit I would probably do it something like this:

To keep the feature branch up-to-date with the upstream branch master 

git checkout master
git pull
git checkout feature
git merge master

And then bypass the review by pushing directly to head

git push origin HEAD:refs/for/feature%submit

Upvotes: 2

Magnus Bäck
Magnus Bäck

Reputation: 11571

You should definitely not squash anything, and unless you and all your developers know what you're doing you shouldn't rebase anything either. Instead, merge from the upstream branch to your feature branch and either upload the resulting merge commit (refs/for/featurebranch) or push it straight past review (refs/heads/featurebranch).

The review of the merge commit won't be very useful as I think it's shown as an empty commit in Gerrit, but having a code review as part of the process can be a way to have someone acknowledge that the merge should be made.

Doing this very frequently will create a somewhat messy history, but you can use basic Git commands to list the differences between the branches (git log --no-merges development..feature etc).

Upvotes: 2

Related Questions