Shell branches with pull request be rebased while the request is pending?

Hi,

in my company, we have a strict rebase policy: Rebase your feature branch on top of the integration branch until it is ready for inclusion. I see that the branches here are usually not rebased before inclusion. A pull-request-based workflow does not make that really deasibe after all. But how are such rebases seen here if done by the pull request issuer during the pull request handling time? Encouraged? Frowned upon? Not seen as an issue?

I just don't want to annoy anyone with my branch handling...

Regards,
Dirk

I don't really see rebasing or not as a problem. I know if new apps have been added at the end of apps.json it can cause a merge error, but it's just a few seconds required for me to fix that so I don't see it as a big deal - and if there are multiple PRs for new apps that I merge within a few minutes of each other it's basically unavoidable.

From my point of view, I just want to be able to clearly see the changes that have been made and to be able to merge, and I'm not too concerned with how we get there. Because apps are pretty much independent it doesn't really matter if other apps are older in your PR - the main thing is that you're applying changes on top of the latest version of that app.

Hope that helps?

I've seen a few cases where PRs have included every change to the repo that happened since the user pulled (like they copied the files from the latest version of the repo over and then committed it) - I believe that's probably just user error (not a proper rebase) but it's important that doesn't happen :)

As I consider myself a git dummy, what would be the best (or easiest way for you to handle) to commit new changes and issue PR for apps?

I usually do the following:

1) before making any changes a do a "fetch and merge from upstream" on my fork of the BangleApps repo
2) commit changes to my fork
3) issue the PR

Is this "the clean" way?

You did not mention creating branch for the feature/PR. Branches are cheap :-)

so it becomes

1) before making any changes a do a "fetch and merge from upstream" on my fork of the BangleApps repo
2) create branch (with descriptive name) and switch to it, commit changes to my fork
3) issue the PR
4) when it gets merged it comes back in master branch when I pull from upstream

but maybe this is automatic and you just did not bother to mention it?

Well thats why I ask ;-)

Pretty sure I am not actively creating a branch. I fetch and merge from upstream online (on the GH page), then in my GitHub Desktop do a fetch on my checked out fork. Then do the changes, commit and push to my fork and then on the GH page issue the PR.

Maybe GH magic is automatically creating a new branch? Dunno. Dummy. ;-)

Hi,

ok, thank you @Gordon, then I will follow a "mixed strategy": Always rebase upon master before issuing any pull requests, and then rebase "from time to time" to stay near to master, but more on a weekly than on a daily base.

To everyone else: Sorry that I did not explain in greater detail what I am actually doing. I work with git for some 14 years now and in my company, we have a quite nice scheme with release branch, integration branch and feature branches. Currently, I work with the Bangle app loader repo as follows:

• I cloned it into my own github namespace ("dirkhillbrecht/BangleApps").

• From there, I cloned it as workspace onto my workstation ("$HOME/Projekte/BangleApps").

• In the workspace, I create a feature branch where I want to change or add stuff: "git checkout -b feature".

• I do all my work in that feature branch.

• I push the feature branch back to my cloned github repo. The first time, I have to give the push target for the new branch explicitly: "git push --set-upstream origin feature".

• When I think I'm finished, I issue a pull request on the feature branch in my cloned github repo back to the official app loader repo.

This way, "master" on my cloned github repo and in my workspace repo can always follow "master" of the official app loader. To stay on top of development, I do the following:

• From time to time, I fetch the updated "master" of the official app loader into my github repo ("Fetch upstream" button).

• I pull the updated master from github to workspace repo ("git checkout master && git pull").

• I switch to my feature branch ("git checkout feature").

• I issue "git rebase master" - and solve any merge issues.

• I push my feature back to my github repo. As it has been rebased and therefore its history is non-linear, I have to push forcefully: "git push --force"

If I do that last step while the branch is already in the pull request review process, other people see my disruptive operation also and potentially must cope with it. I hoped that this was not too big of an issue and learned that it indeed not is.

Regards,
Dirk

Hi, what you're doing sounds fine. However I'd say once you've got that branch for a feature/app it's easiest only to rebase it if you can see something has changed that really affects that app. If other stuff has changed I don't think it really matters