Learn more about triangular workflows, how they work, and how to configure them for your Git workflows. See how you can leverage them on the GitHub CLI.

For those familiar with Git terminology:

The simplest way to assemble a triangular workflow is to set the branch’s merge key to a different branch name, like so:

[branch “branch”]
   remote = origin
   merge = refs/heads/default

This will result in the branch pullRef as origin/default, but pushRef as origin/branch, as shown in Figure 9.

Working with triangular forks requires a bit more customization than triangular branches because we are dealing with multiple remotes. […]

    • abbadon420@lemm.ee
      2·
      22 hours ago

      No, you’re the letter j

      Anyways, I’m assuming you don’t understand what the triangular workflow is (if i assumed wrong, ignore this)? Imagine you want to make an improvement to Lemmy. You got to github.com/lemmynet/lemmy, you fork that repository and you add your improvement. Now you can’t just push you improvement back to that repository, because you don’t have the rights to push to that repository. So you have to make your own repository at github.com/theletterj/lemmy and make a nerge request to github.com/lemmynet/lemmy to merge your improvement.

      That is the triangle. You have to pull from github/lemmynet, but push to guthub/theletterj and send a merge request back to github/lemmynet

        • abbadon420@lemm.ee
          2·
          2 hours ago

          For a single PR it’s pretty much the same, but if you have multiple back and forth, you’d have to set up multiple remotes and switch between them. Now you don’t. If I understand it correctly, you can now just “git pull” from repo1 and “git push” to repo2

  • chonkyninja@lemmy.worldEnglish
    31·
    1 day ago

    Yeah, because fucking Reviewing merge requests, my code is AI generated, it can’t possibly have any errors. /s