• 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

About