I recently forked a project and applied several fixes. I then created a pull request which was then accepted.
A few days later another change was made by another con
I would like to add on to @krlmlr's answer.
Initially, the forked repository has one branch named : master
. If you are working on a new feature or a fix, you would generally create a new branch feature
and make the changes.
If you want the forked repository to be in sync with the parent repository, you could set up a config file(pull.yml
) for the Pull app (in the feature branch), like this:
version: "1"
rules:
- base: feature
upstream: master
mergeMethod: merge
- base: master
upstream: parent_repo:master
mergeMethod: hardreset
This keeps the master
branch of the forked repo up-to-date with the parent repo. It keeps the feature
branch of the forked repo updated via the master
branch of the forked repo by merging the same. This assumes that the feature
branch is the default branch which contains the config file.
Here two mergemethods
are into play, one is hardreset
which helps force sync changes in the master
branch of the forked repo with the parent repo and the other method is merge
. This method is used to merge changes done by you in the feature
branch and changes done due to force sync in the master
branch. In case of merge conflict, the pull app will allow you to choose the next course of action during the pull request.
You can read about basic and advanced configs and various mergemethods
here.
I am currently using this configuration in my forked repo here to make sure an enhancement requested here stays updated.