When forked, "New Branch" is confusing for students

Describe the feature or problem you’d like to solve

Two related problems:

• As a University Lecturer
  I want students to make weekly branches and merges within a student fork So that students can learn a standard development process, I can review their code frequently, they can begin from a starter template, they avoid fiddly repo creation or fork decoupling actions, they are able to diff against my solution code.
  => problem: re-branch is not possible in GHD

• As a Campus Advisor
  I want to promote a simple & intuitive Git Client for teaching
  So that more teachers are able to integrate source control, code review, CICD, etc into their classes
  => problem: I feel uncomfortable promoting GHD when it cannot do something fundamental that every other client in the industry can

Proposed solution

• Solution: Let the user change the source for new branches (i.e. “change” link next to the current source).
• Benefits: Without this feature, my students are forced to leave GitHub Desktop to use the CLI or another Git Client. At that point there is no point using GitHub Desktop. IMO this is a deal-breaker preventing adoption of GHD. With this feature, GHD is my first choice for teaching.

Additional context

My Use Case

I am a lecturer and our university’s GitHub Campus Advisor. I’m trying to promote using GitHub in the classroom. I want to use industry tools & standard development processes as much as possible because I think the best learning environment is a real environment. I don’t want to teach anything artificial that our students have to unlearn later.

I picked GitHub Desktop because it’s no fuss and it “just works”. It seems to me that education should be a major market for GitHub Desktop for this reason.

My students fork their repos from my template. I want to use a fork so that they can easily diff against my solution code. Each week they create a branch and PR their work (to their fork, not upstream). This process teaches them a normal development workflow, facilitates feedback, and allows them to compare their code to mine.

Note: When cloning, my students explicitly select an option to make PRs against their forks, not the upstream.

I accept that there are almost certainly work-arounds; but this does not address problem (2) – in industry the expectation is that I’m able to branch; I don’t want to break that in my classroom environment.

This is not about UX (default source)

IMO defaulting to the upstream is incredibly unintuitive, especially when my forked develop & origin/develop have commits that aren’t in upstream/develop. I would have preferred a warning dialog “your branch is out of date”, and perhaps a checkbox “always pull before branching”. However, this is besides the point!

I don’t care what the default is. I just want to be able to change it, without leaving GHD.

Past Discussions

There is some existing discussion here: https://github.com/desktop/desktop/issues/9384. I tried to pick out some key quotes:

This was an intentional change in #7762 based on the vast majority of forks being used to contribute to the upstream branch. So the previous behavior often would mean people working from forks in Desktop were starting new branches way out of date from the latest commits, and this was intended to help people ensure they’re up to date when starting on a new branch.

The reason why we’ve chosen not to provide a toggle in this particular case is that we think it’s such a limited edge case

I am proposing education as a not-so-limited edge-case. But I accept that other universities may have different processes or be more open to work-arounds (I have a particular aversion to diverging from industry), so I don’t know how big this part of the market is.

[charles-allen]

I think you should be able to search for the relevant verbiage and find it hopefully without too much trouble. The part that’s most relevant to this use case is You can also choose an email local to this repository from the repository settings where repository settings is linked and takes you to the right place.

Thanks! Yes, I should be able to find that; and it will do me good to explore a bit. Wish me luck 😄

[charles-allen]

I think the second one might actually create more confusion […] for people who set things up correctly when asked about how they’re using their fork

This makes sense. I was quite focused on my corner, but now that the issue has been narrowed in scope & value, it’s hard to justify going against the many; and this 2nd approach contradicts the entire design decision to have a settings “switch” for forks.

something we’ve done in other places in the app. If someone wants to take a stab at that in a PR, we’d be happy to review that and see how it feels.

Can you point me at an similar example in the code? If so, I’m happy to have a go at a PR (though I can’t promise I’ll succeed).