Github pull request issue

Question

I have the following scenario:

• my Github default branch is "develop"
• I have three pull request for the "develop" branch
• 3 pull requests are build and verified ok (by CI server)
• then one pull request is manually merged to "develop". '$ bumpversion --commit dev' is executed automatically and the version is build and released. Consequently all files that contain the version change on "develop" (.bumpversion.cfg, module/__init__.py)
• so far so good. Now, due to the changes in "develop" the remaining two pull requests become invalid and can not be merged via the Github GUI any more. I need to checkout the branch and merge with "develop" like @Anirudha describes in detail.
• I do not want my pull requests to become invalid by changes to these two files

I am sure the solution is obvious to the git experts who know how to fix this. So far I could not find it, so please share.

Answer 1

All you need to do is, checkout on those pull requests: git checkout PR1

pull the latest the changes on develop branch. git pull origin develop

Review your corresponding changes. and push to your respective PR. The git remote PR gets updated with new changes and your CI will approve accordingly as well.

Answer 2

I suggest you to do a git rebase for this scenario.

Git Rebase Official Doc

What it does is, checkout to branch you specify while doing a rebase, lets say you have pr#2 and pr#3 pending, You clone the repo and do while in the branch which generated the PR,

git rebase develop

It will say that rebase in prgress, so, you go and solve conflicts in that process, and do a

git add

Now, the rebase either continue or stop if do not have more conflicts. If you have, you can read status in terminal, to continue,

git rebase --continue

Now, do that until all conflicts are resolved.

And finally when you checkout to the branch for that PR, you should see that there are NO conflicts, and branch can be automatically merged (by pushing to remote repo obviously).

Now, repeat the same process for pr#3, and you are done.

In summary,

git rebase develop
git add <files>
git rebase --continue

repeat this for pr#3 also.

Answer 3

You should consider removing version info in your code and only inject it when you really release or deploy the application.

This way your source code is not getting dirty with continues version changes.

Of course you want git to check for changes and tell you when there are conflicts. I suggest you use an alternative solution so conflicts will not occur and merging will become easy. (read through my whole post to have a complete solution)

Partial Solution in your case

Instead of having a definite version have a relative versioning number.

What i mean is this: have a file with release notes. and every time someone does a pull request he adds a row in this file. The file would look like this:

1.0.0 Added a major breaking change
0.1.0 Added a feature
0.0.1 Added a bugfix
1.0.0 Another major change
0.0.1 Bugfix
0.0.1 Another bugfix

On release you calculate your version by either:

• Summing up: 2.1.3
• or Reset after bigger change: 2.0.2 (Proper semver)

Warnings

• for second option: it matters in which order you accept the pull requests. (could lead to different version number)
• Maybe git still wants to merge the same lines (instead of adding them below each other) which still leads to conflicts.

Advantages

• No longer have to worry about the right version number
• Have release notes out of the box

Fixing conflicts

Instead of putting all the version notes in one file: make people write a version note per file like in the following syntax: [yyyy-mm-dd] [1.0.0.0(semVerFix)] [informational note about the change/fix]

/\ Problem is that the versioning might end up being wrong if you accept an newer pull request before the older one and the continues integration kicks of in the mean time.

Final solution

In your git repository.

have a folder called `/release-notes'

If anyone mades a change a file must be added here stating the changes made (preferable you work on one feature or fix at the same time).

This file has the following format [Date] [Version bump] [Description].[Optional file extension] eg: 2016-10-26 1.0.0.0 Added new versioning tooling.txt

As long as date and description are unique you will not have conflicts, unless of-course the code that was changed contains conflicts.

your homework: make tooling that reads these files and accumulates the version number. You could also read the contents of the file and use it as release notes description.

Answer 4

If you cannot rebase those PR branch on top on your new develop (which GitHub proposed recently) because of conflicts, the normal worflow is:

• contact the PR author
• ask him/her to rebase the PR branch on top of a fetched updated origin/develop, solve the conflicts, check that everything is working
• force push the PR branch (that will update the PR, and will trigger a new round of builds by the CI server)

Basically, you need to make sure the PR author is doing all the hard work ;) All you need to do is merge or rebase (without conflicts) when you want to integrate that PR.

Answer 5

Version control should be done via git and not via a file inside the repository. Instead of having a bumpversion.cfg you could use tags for new versions:

git tag 1.0.0 -m "Optional Description or release name."

and have a changelog file which is only changed by bumpversion by accumulating commit titles.

Debian has a git extension to do all this automatically:

git dch

Edit: if you want to add up versions automatically you could have some convention to add the increment to the commit message, ideally via a commit hook. git dch has options to specify which version to increase by the way.