0

I work with other Software Engineers on a web app product. Also, the source code is hosted on GitHub.

There is a behavior pattern that I do not understand. Some co-workers push branches (adding features or fixing bugs) as standalone branches, without an associated Pull Request.

I do not understand this behavior. I can see some disadvantages.

  • For instance, CI scripts with automation and build tests will not run on these standalone branches, but only on branches submitted associated with Pull Requests.
  • Another disadvantage is that standalone branches do not have a comment/review GUI section to discuss the code as Pull Requests have in GitHub.

But, maybe I am missing something on the advantages of this practice.

Is there any advantage of submitting a standalone branch adding a feature or fixing a bug without converting the code into a Pull Request submission?

12
  • 8
    If these branches are longer lived, you get to keep a copy of the code safely stored in the cloud if your drive fails? (And you make the code available to others if you, like, take sick days or something). Feb 2, 2023 at 17:44
  • 7
    What happened when you asked your co-workers why they do this? Feb 2, 2023 at 17:48
  • 3
    @PedroDelfino I think he's being coy, and that's kind of the point. You should ask.
    – Alexander
    Feb 2, 2023 at 19:45
  • 1
    If they cannot see any advantage of doing it your way, then why do it? So the question that you need to address is, why does pull requests bring value to your way of working? Feb 14, 2023 at 13:10
  • 2
    @PedroDelfino Not for us, for your coworkers! Have you asked them? Feb 14, 2023 at 13:30

3 Answers 3

5

Small features / bugfixes can be added, tested, pushed, and a PR created all within a short time span - maybe a couple of hours. In those cases, there's not much reason to push a branch without creating the PR. If you lose the work, it's not all that much effort to recreate it.

For larger changes, though, pushing to the server provides a second copy of the work-in-progress code. The work is not done, so it's not appropriate to create a PR. However, this second copy provides a backup in case your computer dies. It allows others to see - and continue - your work, in case you're out sick, go on vacation, get hit by a bus, etc. It allows others to start building off your work, if needed (not recommended, but sometimes unavoidable). It also allows you to access the code from different computers (maybe one in the office, one while working from home), which may be beneficial depending on your workflow.

I'm sure there are other reasons as well, this is not an exhaustive list.

9
  • 3
    What's the actual benefit of creating a PR draft? Maybe they don't expect it to build yet and there's no point running CI.
    – Useless
    Feb 2, 2023 at 18:52
  • 1
    also, just sharing the code, asking for help etc
    – Ewan
    Feb 2, 2023 at 18:56
  • 1
    @PedroDelfino - "If the work is not ready, why not creating a PR draft?" - well, maybe they are not ready for code review yet, and don't want to bother people. Maybe they are pushing to that branch every 10-20 min. Maybe they want to merge in someone else's changes and resolve conflicts before making the PR. People work in different ways. You can create a PR from the branch later. Feb 2, 2023 at 19:38
  • 2
    @PedroDelfino I do it because I don't want to pollute my draft PRs timeline with tons of spam push/force-push events. Those spammy events aren't wiped when the PR is published as ready-to-review, so it just adds needless noise. I create a draft PR when I'm actually ready to solicit early feedback from coworkers.
    – Alexander
    Feb 2, 2023 at 19:44
  • 2
    Real life story.. we had a developer who worked on a feature for about 4 weeks. Then they disappeared, basically ghosted the team. No remote branch. All work was not recovered. We had to start over. That promised feature was not delivered in that cycle. If they had pushed to a remote branch we could have taken what was done and continued it and finished.
    – Jon Raynor
    Feb 2, 2023 at 21:04
2

For instance, CI scripts with automation and build tests will not run on these standalone branches, but only on branches submitted associated with Pull Requests.

That depends on how you have your CI set up. You can run builds on every branch push, if you want to.

Another disadvantage is that standalone branches do not have a comment/review GUI section to discuss the code as Pull Requests have in GitHub.

Well, that's the point, isn't it? If someone wanted to start that discussion, they would create a PR. Since they didn't, we can infer that they had something else in mind. Maybe they're just moving from one machine to another and they need somewhere to stash their work-in-progress. Maybe it's a staging area for aggregating changes from other branches. Maybe it contains an experiment, or a reproducer for a bug, which is useful to show someone else, but which doesn't pass tests and isn't ever intended to be merged.

Github is still git, and git still supports a lot more workflows and usecases than the "make a PR and merge it" one.

2

I feel like I should first address some apparent premises that this kind of question is based on.

Being able to share code to a remote repository that multiple people have access to (read-write or just read) is the bread-and-butter of repository-based Git workflows[1] that involve more than one person. That’s very powerful in itself.

In fact, it’s the foundation on top of which all the forges (like GitHub) are built.

So turn the question on its head: do you need the forge-exclusive stuff?

Yes, they’re powerful as well. In particular being able to comment on individual lines is very convenient.

But they are extras that you don’t need on every occassion.

It’s like git(1): a suite of commands (maybe a hundred?), but on most days you might only use a handful.


Some use-cases:

  • Someone asked you about something you are working on right now, so you push the branch for them to see what it’s about
  • Two of you are working on something related, so you agree that the other person will base their work on top of your branch
  • Someone else had a nice temporary workaround for an issue that you also are having, so they push a branch which you can temporarily rebase or cherry-pick into your branch as temporary commits (to be removed later) so you can get back to whatever you are working on
  • You have some changes that doesn’t need a PR to review. You agree with two other people that they are going to merge it into the main branch after being able to look at the diffs and playing with it in their own local repositories
    • You DM them that you pushed a branch to the repository instead of both pushing a branch and making a PR

Postscript

There’s value in appreciating the “basics” and how you can get quite far with just one suite of tools (like what git(1) is) without relying on something else (GitHub can be used as a code hoster without any of the GitHub-extra stuff).

Notes

  1. Meaning workflows where you coordinate your work through either one shared remote repository or via multiple. This is not a standard term or anything.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.