0

I work with other Software Engineers on a web app product. Also, the source code is hosted on GitHub.

Recently, there was an introduction of a Continuous Integration procedure enabled by a script written as a yml file and GitHub Actions.

After every Pull Request on GitHub, the CI script checks if the new code is breaking the application or if everything goes well. The construction of the dependency tree is a specially delicate part of the process. Hence, the dependencies used in the source code need to be the same declared on the CI's "build recipe".

A problem we have is that sometimes the main branch is getting updated and evolving while the Pull Request has not been approved yet. This means the PR is behind main branch.

By definition, the CI build script is not going to work under such conditions because the PR might have an older version of it while main branch has a newer/current version of the project. As a consequence, for the CI to work well PRs need to always be on top of cutting-edge main.

The way I usually solve this is by going to the PR's branch, pulling into the PR's branch from origin/main and doing a rebase of local commits. Sometimes, merge conflicts will arise and I will need to solve them. It works. If the PR becomes obsolete again, I can do multiple iterations of the interactive rebase pulling from the latest remote main. Since I am changing the order of history, it will probably be necessary to force push the changes when pushing them.

Ok.

Other members of the team prefer a different approach. They prefer to locally merge the latest main on the local PR branch.

Apparently, the team treats both processes as "equivalent" and open to "personal preferences".

However, I am not sure about this claim technically speaking.

Thus, I would like to ask:

0 - What is the correct way to deal with Pull Request updates concerning an interface with a Continuous Integration script: rebase or merge?

1 - Is merging locally equivalent to the interactive rebase approach?

2 - Is merging locally also going to create an obligation for force pushes?

3 - Pulling from main and doing an interactive rebase can be done multiple times. Is it possible to repeat multiple times the merge procedure?

Improve this question
6
  • 2
    Any technique involving "force push" is a technique I avoid. Also, your CI approach sounds too fragile. Adopt SemVer for it, and consider hosting the relevant CI code in a different repo. You described frequent Breaking changes, which implies bumping a major version number. Keep old major versions available for as long as it takes to merge down PRs.
    – J_H
    Feb 1 at 18:36
  • 1
    @J_H How do you feel about lease?
    – candied_orange
    Feb 1 at 21:38
  • 1
    I don't understand this "the CI build script is not going to work under such conditions". Is this a problem you've had, or is it a problem you're anticipating? In general the CI / build script should be part of the same source control system as the rest of the c ode, so any build will use matching versions of build script and application code.
    – bdsl
    Feb 1 at 21:39
  • @candied_orange, I did not say that on my original post. But, yes. When I force push things, it is always with --force-with-lease. I forgot to mention that.
    – Pedro Delfino
    Feb 1 at 22:49
  • @J_H, we are in the process of having all dependencies as Maven packages in our private GitHub registry. And, half of our system already has a CD procedure deploying automatically a Maven package for our dependencies. After all dependencies have maven packages, the CI will consume them from the shadow-cljs.edn declaration. The process will be more robust then.
    – Pedro Delfino
    Feb 1 at 22:51

1 Answer 1

Reset to default
3

0 - What is the correct way to deal with Pull Request updates concerning an interface with a Continuous Integration script: rebase or merge?

There is no intrinsically correct way. Both rebase and merge commits can do the job.

One thing to really watch out for is that you will end up with a lot of pain when you try to apply both approaches to a single branch. And that is not related to the CI scripts, but with the fact that rebasing a branch that contains merge commits is just painful.

1 - Is merging locally equivalent to the interactive rebase approach?

Yes, to the extent that you end up with the same delta with your base branch.

2 - Is merging locally also going to create an obligation for force pushes?

No.

3 - Pulling from main and doing an interactive rebase can be done multiple times. Is it possible to repeat multiple times the merge procedure?

Yes, it is entirely possible to merge the main branch multiple times into your feature branch.

Apparently, the team treats both processes as "equivalent" and open to "personal preferences".

The two processes are roughly "equivalent", but as I stated above, using both on a single branch will lead to a painful experience. For that reason, I strongly advocate to not make it a matter of "personal preference", but a matter of "team preference".

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.