Cwa-app-ios: Clarification needed: Which is your 'development branch' (starting point for new branches)?

[ndegendogo]

Avoid duplicates

• [ ] Question is not already answered in the FAQ
• [ ] Question has not already been asked in another issue

Your Question

• File:
  https://github.com/corona-warn-app/cwa-app-ios/blob/release/1.13.x/CONTRIBUTING.md#pull-request-checklist

• Question:
  Which branch should I use if I want to prepare for a Pull Request?

Your 'Pull Request Checklist' at https://github.com/corona-warn-app/cwa-app-ios/blob/release/1.13.x/CONTRIBUTING.md#pull-request-checklist mentions to "branch from the development branch". There is a branch of this name 'develop', but this branch seems stale (last commit was in October 2020). My best guess is to use the branch marked as 'default' on github - today this is 'release/1.13.x'.

[Ein-Tim]

@ndegendogo

For my (very small) PRs I always branched from the default branch. This worked 👍

[ndegendogo]

Thanks @Ein-Tim!
... actually, I am currently struggling to setup my environment correctly ... and this is always more work than you expect from the beginning ... 😬

[ndegendogo]

@Ein-Tim but maybe you have some hints for me ...

How exactly do you keep your fork in-sync with the upstream (original cwa project)? Are you using the git command-line for this? Or is there some tools to make it easier?

[Ein-Tim]

@ndegendogo

For sure.

So I'm using GitKraken to keep an overview where my fork is.
GitKraken is able to keep the fork in sync AFAIK but I did not yet discover how to do it (correctly).
So yes, the only way at the moment for me was to use the Git command line...

[ndegendogo]

use the Git command line...

@Ein-Tim Perfect! 😀 Could you give me more details?

[Ein-Tim]

@ndegendogo

I always used git pull upstream BRANCH

For BRANCH you write the branch you are forking from (Release 1.13.x, etc.).

But what also should be possible is that you do your work in your fork, and as you maybe know GitHub will give you an option to update the branch as soon as you open a PR here.
This always worked fine for me in the website repo, as long as there are no conflicting files (my changes vs. incoming changes).

Also you should definitely check your editor that it does not make any whitespace changes, this drove me crazy in 2 PRs in the website repo.

I hope this helped a bit 😀

[ndegendogo]

I always used git pull upstream BRANCH

yes, this I am currently trying - good to know that I still seem to be on the right track 😅

GitHub will give you an option to update the branch as soon as you open a PR here

ah - this is interesting!
Actually this was what I am looking for all the time - Thanks a lot!

definitely check your editor that it does not make any whitespace changes

yes, definitely! whitespace is always a good source for unwanted merge conflicts! 🤪

[dsarkar]

@ndegendogo Hi, are your questions all answered, or do need some more info?

[ndegendogo]

Good morning @dsarkar - thanks for asking!
Currently I am assuming that branching from 'release/1.13.x' is ok. (Actually, I have even started with a branch from release/1.12.x because that was easier for me, but for the PR I can transfer my work to the other branch, no problem).
I will definitely have more questions and need for discussion (maybe tomorrow), and I am considering to split this ticket, but at the moment I am not blocked.

Have a nice weekend!

[heinezen]

@ndegendogo

The official answer is to always branc from the latest release branch (which should be set as the default branch). I'll try to get this updated in the docs, so please do not close :)

How exactly do you keep your fork in-sync with the upstream (original cwa project)? Are you using the git command-line for this? Or is there some tools to make it easier?

You either rebase or merge the upstream branch into your local branch. Git GUI interfaces will make this job a lot easier for you. You don't need to do this every time upstream is updated, just once when you open the PR.

---

Corona-Warn-App Open Source Team

[ndegendogo]

Thanks @heinezen !

always branc from the latest release branch

This makes a lot of sense. A release branch is supposed to have a good quality; and merging forward is always cleaner than backwards.

latest release branch (which should be set as the default branch

Wait - now I am a bit confused again - what exactly is the "latest" release branch?

• the latest which was actually released to public (which is currently 1.11.x, should be very stable if not frozen)
• the next planned release (which is currently 1.12.x, should also be quite stable now)
• the 'youngest' available release branch (currently 1.13.x, and this is marked as 'default' in github)

Note: youngest release branch also makes a lot of sense, this strategy focusses on getting the 'older' release branches stable.

[heinezen]

@ndegendogo "latest" in terms of development is always the youngest release branch because that's where changes are still possible without blocking pre-release testing.

---

Corona-Warn-App Open Source Team