Github pull request issue

 

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.

    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.

    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.

    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.

    链接地址: http://www.djcxy.com/p/68536.html

    上一篇: 为特定用户获取问题并提取请求

    下一篇: Github拉请求问题