# branch

Published articles for branch.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Fixing two minor git irritations in my OSS fork workflow

DevFeed: [Fixing two minor git irritations in my OSS fork workflow](<https://devfeed.tech/articles/fixing-two-minor-git-irritations-in-my-oss-fork-workflow-39468.md>)

Original publisher: [Read original article](<https://akrabat.com/fixing-two-minor-git-irritations-in-my-oss-fork-workflow/>)

Author: Rob

Published: 2026-05-26T10:00:00Z

Content type: tutorial

Language: en

Sources: [Rob Allen](<https://devfeed.tech/sources/rob-allen.md>)

Topics: [Git](<https://devfeed.tech/topics/git.md>), [Pull Request](<https://devfeed.tech/topics/pull-request.md>)

Tags: [branch](<https://devfeed.tech/tags/branch.md>), [development](<https://devfeed.tech/tags/development.md>), [fork](<https://devfeed.tech/tags/fork.md>), [git](<https://devfeed.tech/tags/git.md>), [oss](<https://devfeed.tech/tags/oss.md>), [project](<https://devfeed.tech/tags/project.md>), [remote](<https://devfeed.tech/tags/remote.md>), [repo](<https://devfeed.tech/tags/repo.md>), [workflow](<https://devfeed.tech/tags/workflow.md>)

### AI overview

A practical guide to reducing two minor irritations in an open-source Git fork workflow: ensuring the local main branch tracks upstream/main and configuring new branches to push to origin automatically on their first push.

### Source excerpt

For OSS work, I work with two git remotes: upstream: the canonical OSS project repository, where main is the default branch and is what gets released. origin: a personal fork. All my feature branches live here. I set up locally like this: Fork the project repo to my account. Clone my fork locally, so the origin remote is my fork. Set an upstream remote using git remote add upstream <ssh-url>. and then when working on... continue reading.

## AI-assisted coding can outpace code review, increasing the need for smaller PRs and clearer architecture context

DevFeed: [AI-assisted coding can outpace code review, increasing the need for smaller PRs and clearer architecture context](<https://devfeed.tech/articles/the-ai-code-review-bottleneck-when-writing-code-is-5x-faster-but-reviewing-is-2x-slower-39581.md>)

Original publisher: [Read original article](<https://ankit-rana.com/logs/29-ai-code-review-bottleneck/>)

Author: hello@ankit-rana.com

Published: 2026-05-17T00:00:00Z

Content type: article

Language: en

Sources: [Ankit Rana | Mechanical Sympathy](<https://devfeed.tech/sources/ankit-rana-mechanical-sympathy.md>)

Topics: [AI-assisted coding](<https://devfeed.tech/topics/ai-assisted-coding.md>), [Code review](<https://devfeed.tech/topics/code-review.md>), [Pull Request](<https://devfeed.tech/topics/pull-request.md>), [Latency](<https://devfeed.tech/topics/latency.md>), [Network](<https://devfeed.tech/topics/network.md>), [Hardware](<https://devfeed.tech/topics/hardware.md>), [Database](<https://devfeed.tech/topics/database.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [branch](<https://devfeed.tech/tags/branch.md>), [cloud](<https://devfeed.tech/tags/cloud.md>), [code-review](<https://devfeed.tech/tags/code-review.md>), [cost](<https://devfeed.tech/tags/cost.md>), [hardware](<https://devfeed.tech/tags/hardware.md>), [incident](<https://devfeed.tech/tags/incident.md>), [latency](<https://devfeed.tech/tags/latency.md>), [network](<https://devfeed.tech/tags/network.md>), [production](<https://devfeed.tech/tags/production.md>), [productivity](<https://devfeed.tech/tags/productivity.md>), [review](<https://devfeed.tech/tags/review.md>), [system-design](<https://devfeed.tech/tags/system-design.md>), [writing-code](<https://devfeed.tech/tags/writing-code.md>)

### AI overview

AI-assisted coding can make implementation much faster than review. The article explains that reviewers must reconstruct context, trace data flow, and assess hardware, network, latency, connection-pool, and architecture implications. It recommends keeping AI-written PRs small, documenting operational costs, and showing network boundaries early.

### Source excerpt

AI made writing code a local, fast operation while review stayed cold and global: the reviewer must reload architecture, trace data flow, and mentally simulate hardware and network cost. A 400-line PR can take twice as long to review as it took to generate. Keep AI-written PRs under 100 lines, state endpoint count and expected latency in the description, and show the network boundary up front.

## Branch Prediction: Why an if Inside a Hot Loop Costs Milliseconds

DevFeed: [Branch Prediction: Why an if Inside a Hot Loop Costs Milliseconds](<https://devfeed.tech/articles/branch-prediction-why-an-if-inside-a-hot-loop-costs-milliseconds-39571.md>)

Original publisher: [Read original article](<https://ankit-rana.com/logs/19-branch-prediction-loop-unrolling/>)

Author: hello@ankit-rana.com

Published: 2026-03-21T00:00:00Z

Content type: tutorial

Language: en

Sources: [Ankit Rana | Mechanical Sympathy](<https://devfeed.tech/sources/ankit-rana-mechanical-sympathy.md>)

Topics: [cpu](<https://devfeed.tech/topics/cpu.md>), [Hardware](<https://devfeed.tech/topics/hardware.md>)

Tags: [branch](<https://devfeed.tech/tags/branch.md>), [branch-prediction](<https://devfeed.tech/tags/branch-prediction.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [cycles](<https://devfeed.tech/tags/cycles.md>), [loops](<https://devfeed.tech/tags/loops.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [performance](<https://devfeed.tech/tags/performance.md>), [pipeline](<https://devfeed.tech/tags/pipeline.md>), [pipelining](<https://devfeed.tech/tags/pipelining.md>), [sorting](<https://devfeed.tech/tags/sorting.md>), [systems](<https://devfeed.tech/tags/systems.md>), [wall-clock-time](<https://devfeed.tech/tags/wall-clock-time.md>)

### AI overview

This tutorial explains how CPU pipelining and branch prediction affect performance in hot loops. It describes the cost of mispredictions and suggests sorting data to create predictable branch patterns or using branchless techniques and loop unrolling, while recommending measurement on the target workload.

### Source excerpt

CPUs pipeline instructions and speculate on branch outcomes. A misprediction discards the speculative work and flushes the pipeline at roughly 10 to 20 cycles. In a million-iteration loop with random branch outcomes, those flushes dominate runtime. Sorting the data so the branch resolves the same way for long runs, or removing the branch entirely with a mask or 0/1 multiplier, is what recovers the time.

## first-class merges and cover letters

DevFeed: [first-class merges and cover letters](<https://devfeed.tech/articles/first-class-merges-and-cover-letters-36222.md>)

Original publisher: [Read original article](<https://dotat.at/@/2025-09-11-cover-letter.html>)

Published: 2025-09-11T01:26:47Z

Content type: opinion

Language: en

Sources: [Tony Finch's blog](<https://devfeed.tech/sources/tony-finch-s-blog.md>)

Topics: [Git](<https://devfeed.tech/topics/git.md>), [version-control](<https://devfeed.tech/topics/version-control.md>), [Development](<https://devfeed.tech/topics/development.md>), [pull-requests](<https://devfeed.tech/topics/pull-requests.md>), [Code review](<https://devfeed.tech/topics/code-review.md>)

Tags: [branch](<https://devfeed.tech/tags/branch.md>), [git](<https://devfeed.tech/tags/git.md>), [merge](<https://devfeed.tech/tags/merge.md>), [review](<https://devfeed.tech/tags/review.md>), [version-control](<https://devfeed.tech/tags/version-control.md>), [workflow](<https://devfeed.tech/tags/workflow.md>)

### AI overview

This commentary examines shortcomings in Git branches and common merge and rebase workflows. It argues that improving merges, rather than branches alone, could make branch-based development more effective, while considering trade-offs between detailed history and clean logical changes.

### Source excerpt

Although it looks really good, I have not yet tried the Jujutsu (jj) version control system, mainly because it's not yet clearly superior to Magit. But I have been following jj discussions with great interest. One of the things that jj has not yet tackled is how to do better than git refs / branches / tags. As I underestand it, jj currently has something like Mercurial bookmarks, which are more like raw git ref plumbing than a high-level porcelain feature. In particular, jj lacks signed or annotated tags, and it doesn't have branch names that always automatically refer to the tip. This is clearly a temporary state of affairs because jj is still incomplete and under development and these gaps are going to be filled. But the discussions have led me to think about how git's branches are unsatisfactory, and what could be done to improve them. branch merge rebase squash fork cover letters previous branch workflow questions branch One of the huge improvements in git compared to Subversion was git's support for merges. Subversion proudly advertised its support for lightweight branches, but a branch is not very useful if you can't merge it: an un-mergeable branch is not a tool you can use to help with work-in-progress development. The point of this anecdote is to illustrate that rather than trying to make branches better, we should try to make merges better and branches will get better as a consequence. Let's consider a few common workflows and how git makes them all unsatisfactory in various ways. Skip to cover letters and previous branch below where I eventually get to the point. merge A basic merge workflow is, create a feature branch hack, hack, review, hack, approve merge back to the trunk The main problem is when it comes to the merge, there may be conflicts due to concurrent work on the trunk. Git encourages you to resolve conflicts while creating the merge commit, which tends to bypass the normal review process. Git also gives you an ugly useless canned commit messa

## Dura: Automatic Background Commits for Git Repository Recovery

DevFeed: [Dura: Automatic Background Commits for Git Repository Recovery](<https://devfeed.tech/articles/just-commit-more-33416.md>)

Original publisher: [Read original article](<https://timkellogg.me/blog/2022/10/04/dura>)

Published: 2022-10-04T00:00:00Z

Content type: opinion

Language: en

Sources: [Tim Kellogg](<https://devfeed.tech/sources/tim-kellogg.md>)

Topics: [Git](<https://devfeed.tech/topics/git.md>), [Rust](<https://devfeed.tech/topics/rust.md>), [Nix](<https://devfeed.tech/topics/nix.md>)

Tags: [backup](<https://devfeed.tech/tags/backup.md>), [branch](<https://devfeed.tech/tags/branch.md>), [code-reviews](<https://devfeed.tech/tags/code-reviews.md>), [commit](<https://devfeed.tech/tags/commit.md>), [git](<https://devfeed.tech/tags/git.md>), [rust](<https://devfeed.tech/tags/rust.md>)

### AI overview

The author describes dura, a Rust tool that automatically makes background Git commits on a separate branch. The article explains how this creates a timestamp-ordered record of changes that can help recover abandoned work, resets, merges, and other difficult repository states.

### Source excerpt

Over new years this past year I made dura. It's like auto-backup for Git. It tries to stay out of the way until you're in a panic, trying to figure out how to rescue your repository from a thoughtless git reset --hard. It makes background commits, real Git commits that you don't normally have to see in the log, by committing to a different branch than the one you have checked out. Overall, it's been a blast. I've learned a lot from the contributors, like how to write well-formed Rust as well as a bit about Nix.

## Git: check if a folder changed

DevFeed: [Git: check if a folder changed](<https://devfeed.tech/articles/git-check-if-a-folder-changed-37721.md>)

Original publisher: [Read original article](<https://carlosbecker.com/posts/git-changed/>)

Author: Carlos Alexandro Becker

Published: 2019-04-11T00:00:00Z

Content type: tutorial

Language: en

Sources: [Carlos Becker](<https://devfeed.tech/sources/carlos-becker.md>)

Topics: [Git](<https://devfeed.tech/topics/git.md>), [Script](<https://devfeed.tech/topics/script.md>)

Tags: [branch](<https://devfeed.tech/tags/branch.md>), [changes](<https://devfeed.tech/tags/changes.md>), [deploy](<https://devfeed.tech/tags/deploy.md>), [files](<https://devfeed.tech/tags/files.md>), [git](<https://devfeed.tech/tags/git.md>), [lint](<https://devfeed.tech/tags/lint.md>)

### AI overview

A quick guide to checking whether files in a folder changed between Git revisions, including comparisons with the current branch or a previous tag. The technique can conditionally deploy changed folders or lint changed files.

### Source excerpt

Often I need to "do X only if files on some folder changed" or whatever. I always need to Google that or find it on old scripts...

## The Life of a GitHub Action

DevFeed: [The Life of a GitHub Action](<https://devfeed.tech/articles/the-life-of-a-github-action-35207.md>)

Original publisher: [Read original article](<https://blog.jessfraz.com/post/the-life-of-a-github-action/>)

Published: 2019-01-13T15:09:26Z

Content type: tutorial

Language: en

Sources: [Jessie Frazelle](<https://devfeed.tech/sources/jessie-frazelle.md>)

Topics: [GitHub](<https://devfeed.tech/topics/github.md>), [Code](<https://devfeed.tech/topics/code.md>), [Pull Request](<https://devfeed.tech/topics/pull-request.md>)

Tags: [branch](<https://devfeed.tech/tags/branch.md>), [cleanup](<https://devfeed.tech/tags/cleanup.md>), [code](<https://devfeed.tech/tags/code.md>), [github](<https://devfeed.tech/tags/github.md>), [github-action](<https://devfeed.tech/tags/github-action.md>), [pull-request](<https://devfeed.tech/tags/pull-request.md>), [repository](<https://devfeed.tech/tags/repository.md>), [workflow](<https://devfeed.tech/tags/workflow.md>)

### AI overview

This tutorial explains what happens when a GitHub Action runs, using a workflow that deletes a repository branch after its pull request is merged. It introduces the workflow file, triggering pull request events, and the Action execution flow.

### Source excerpt

I thought it might be fun to write a blog post on "The Life of a GitHub Action." When you go through orientation at Google they walk you through "The Life of a Query" and it was one of my favorite things. So I am re-applying the same for a GitHub Action. For those unfamiliar Actions was a feature launched at GitHub's conference Universe last year. You can sign up for the beta here. The overall idea is scriptable GitHub but rather than do all that hand-wavy crap to try and explain I will take you through what happens when you run an Action. The Problem Here is a typical workflow: I create a pull request on a repository. The pull request is merged. The branch lingers around until the end of time and eats away at the part of my soul that likes everything to be clean. Let's focus on my pain of the lingering branches. This is totally a problem right? So let's solve it by creating an Action to delete branches after the pull request has been merged. All the code for this action lives here if you want to skip ahead. The Workflow File You can create actions from the UI or you can write the Workflow file yourself. In this post, I am just going to use a file. Here is what it ends up looking like and I will explain what everything means in comments on the file. This lives in .github/main.workflow in your repository. ## Workflow defines what we want to call a set of actions. workflow "on pull request merge, delete the branch" { ## On pull_request defines that whenever a pull request event is fired this ## workflow will be run. on = "pull_request" ## What is the ending action (or set of actions) that we are running. ## Since we can set what actions "need" in our definition of an action, ## we only care about the last actions run here. resolves = ["branch cleanup"] } ## This is our action, you can have more than one but we just have this one for ## our example. ## I named it branch cleanup, and since it is our last action run it matches ## the name in the resolves section above. a

## Screencast: Using Pretender to mock a server with Ember.js

DevFeed: [Screencast: Using Pretender to mock a server with Ember.js](<https://devfeed.tech/articles/screencast-using-pretender-to-mock-a-server-with-ember-js-40632.md>)

Original publisher: [Read original article](<https://eviltrout.com/blog/2014-08-26-pretender/>)

Published: 2014-08-26T00:00:00Z

Content type: tutorial

Language: en

Sources: [Robin Ward](<https://devfeed.tech/sources/robin-ward.md>)

Topics: [Ember](<https://devfeed.tech/topics/ember.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [test](<https://devfeed.tech/topics/test.md>), [Library](<https://devfeed.tech/topics/library.md>), [GitHub](<https://devfeed.tech/topics/github.md>)

Tags: [branch](<https://devfeed.tech/tags/branch.md>), [ember](<https://devfeed.tech/tags/ember.md>), [integration-test](<https://devfeed.tech/tags/integration-test.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [js](<https://devfeed.tech/tags/js.md>), [library](<https://devfeed.tech/tags/library.md>), [login](<https://devfeed.tech/tags/login.md>), [mock](<https://devfeed.tech/tags/mock.md>)

### AI overview

A screencast demonstrates how to use Pretender, a JavaScript mock server library, in an Ember.js integration test. The source code for the login application is available on GitHub, with the finished version in the pretender branch.

### Source excerpt

Recently I fell in love with Pretender, the mock server library in Javascript, so I decided to record a screencast showing how to use it in an Ember.js integration test: The source code for the login application is on github. The finished version is in the pretender branch.

## How to prepare a clean pull request from a fork that has diverged from its upstream repository

DevFeed: [How to prepare a clean pull request from a fork that has diverged from its upstream repository](<https://devfeed.tech/articles/when-pull-requests-get-tricky-35550.md>)

Original publisher: [Read original article](<https://meowni.ca/posts/tricky-pull-requests/>)

Author: Monica Dinculescu

Published: 2014-02-25T00:00:00Z

Content type: tutorial

Language: en

Sources: [Monica Dinculescu](<https://devfeed.tech/sources/monica-dinculescu.md>)

Topics: [Pull Request](<https://devfeed.tech/topics/pull-request.md>), [Git](<https://devfeed.tech/topics/git.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [branch](<https://devfeed.tech/tags/branch.md>), [changes](<https://devfeed.tech/tags/changes.md>), [future](<https://devfeed.tech/tags/future.md>), [git](<https://devfeed.tech/tags/git.md>), [merge](<https://devfeed.tech/tags/merge.md>), [pull-requests](<https://devfeed.tech/tags/pull-requests.md>), [test](<https://devfeed.tech/tags/test.md>)

### AI overview

This tutorial explains how to create a clean pull request when a fork has diverged from its upstream repository. It covers configuring an upstream remote, creating a branch from an earlier synchronized commit, reapplying or selectively extracting changes, merging upstream changes, testing, and uploading the branch.

### Source excerpt

Imagine this: you have forked a repo a long time ago and have since been in a happily committed relationship with the master branch, modifying files and committing from the hip. In case you have doubts about the likelihood of this scenario, we're talking about my notwaldorf.github.com blog branch, which I forked from holman/left. All my changes are on the master branch so that GitHub can do its magic gh-pages trick and just Make Things Work™. This could also happen for repos you've forked and mucked around with, but never thought you'd ever contribute to. Because you're a good open sorcerer, you might, at some point, want to send a pull request to fix a thing in the original repo. If you're anything like I am, you are now in a bit of a terrible situation because your fork's tip of tree has advanced and diverged quite a bit from the upstream repo, so any pull requests you send out will be polluted with code that doesn't belong in them. At this point, you probably have some regrets. Let's not dwell on them. Here's the set of steps that will help you navigate this minefield you find yourself in. They're not special; I just couldn't find them all in one place, and wanted a summary for the future. Kamal figured most of this out, because he is a git wizard, while I am, most definitely, not. Set up your upstream If git remote doesn't show you a branch called upstream, you need to add one: git remote add upstream https://github.com/user/repo_you_forked.git Set up a clean branch for your fix Step into your tardis and branch from when you were last in sync with the upstream. In my case, this was when I initially created my fork. A dull perusing of git log or git reflog should point you to the right sha. Then, git checkout -b pr_branch git reset --hard sha_from_the_past Get your changes in Here you have two options. If your changes are tiny, or you know exactly what they are, you can just manually reapply them. And by that I mean copy paste the changes into the right files, li

## Git Tips and Commands for Commit Management, Repositories, and File History

DevFeed: [Git Tips and Commands for Commit Management, Repositories, and File History](<https://devfeed.tech/articles/git-protipstm-37722.md>)

Original publisher: [Read original article](<https://carlosbecker.com/posts/git-protips/>)

Author: Carlos Alexandro Becker

Published: 2013-02-08T00:00:00Z

Content type: tutorial

Language: en

Sources: [Carlos Becker](<https://devfeed.tech/sources/carlos-becker.md>)

Topics: [Git](<https://devfeed.tech/topics/git.md>), [version](<https://devfeed.tech/topics/version.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [branch](<https://devfeed.tech/tags/branch.md>), [commands](<https://devfeed.tech/tags/commands.md>), [commit](<https://devfeed.tech/tags/commit.md>), [git](<https://devfeed.tech/tags/git.md>), [history](<https://devfeed.tech/tags/history.md>), [patches](<https://devfeed.tech/tags/patches.md>), [revision](<https://devfeed.tech/tags/revision.md>), [ssh](<https://devfeed.tech/tags/ssh.md>), [tips](<https://devfeed.tech/tags/tips.md>), [tricks](<https://devfeed.tech/tags/tricks.md>)

### AI overview

A practical collection of Git commands and tips covering commit management, reflogs, file restoration, shallow clones, branches, staging, and stashing. It also notes that SSH keys can be used to sign Git commits and tags instead of GPG.

### Source excerpt

Git has a lot of features, and I bet that 90% of who use it (including me) doesn't know half of them. Well, maybe, someday, one of those "unknown features" can "save your life".

## Cleaning up old git branches

DevFeed: [Cleaning up old git branches](<https://devfeed.tech/articles/cleaning-up-old-git-branches-35379.md>)

Original publisher: [Read original article](<https://darkcoding.net/software/cleaning-up-old-git-branches/>)

Author: Graham King

Published: 2011-09-16T19:14:15Z

Content type: tutorial

Language: en

Sources: [Graham King](<https://devfeed.tech/sources/graham-king.md>)

Topics: [Git](<https://devfeed.tech/topics/git.md>)

Tags: [branch](<https://devfeed.tech/tags/branch.md>), [browser](<https://devfeed.tech/tags/browser.md>), [commit](<https://devfeed.tech/tags/commit.md>), [delete](<https://devfeed.tech/tags/delete.md>), [git](<https://devfeed.tech/tags/git.md>), [software](<https://devfeed.tech/tags/software.md>), [tips](<https://devfeed.tech/tags/tips.md>), [tracker](<https://devfeed.tech/tags/tracker.md>)

### AI overview

A practical guide to cleaning up old Git branches by checking whether branches are merged, reviewing their last commit dates and related tracker status, deleting stale local branches, and synchronizing remote branch names.

### Source excerpt

Tame your git branch jungle with these handy tips.