# When You Forget Your Branch Name Use Git Reflog

DevFeed: [When You Forget Your Branch Name Use Git Reflog](<https://devfeed.tech/articles/when-you-forget-your-branch-name-use-git-reflog-28170.md>)

Original publisher: [Read original article](<http://fuzzyblog.io/blog/git/2019/11/25/when-you-forget-your-branch-name-use-git-reflog.html>)

Author: Fuzzygroup

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

Content type: tutorial

Language: en

Sources: [Scott Johnson](<https://devfeed.tech/sources/scott-johnson.md>)

Topics: [Git](<https://devfeed.tech/topics/git.md>), [version-control](<https://devfeed.tech/topics/version-control.md>), [GitHub Issues](<https://devfeed.tech/topics/github-issues.md>), [Pull Request](<https://devfeed.tech/topics/pull-request.md>), [ci](<https://devfeed.tech/topics/ci.md>)

Tags: [cmn](<https://devfeed.tech/tags/cmn.md>), [command](<https://devfeed.tech/tags/command.md>), [commit](<https://devfeed.tech/tags/commit.md>), [git](<https://devfeed.tech/tags/git.md>), [github](<https://devfeed.tech/tags/github.md>), [github-issues](<https://devfeed.tech/tags/github-issues.md>), [pull-request](<https://devfeed.tech/tags/pull-request.md>), [version-control](<https://devfeed.tech/tags/version-control.md>)

## AI overview

This article explains how Git reflog can help recover the name of a branch that was forgotten in a workflow using issue branches, pull requests, and separate master and develop branches. The author uses reflog output, including local dates, to identify the branch and resume work.

## Source excerpt

For my current side project, cmn, I'm using a version control model of issue branches as described here back in June (about when I started this). Basically the model is: The master branch is always pristine and always deployable. The develop branch takes changes from issue branches and is then merged into master by a CI server. Anything you work on, no matter how small, gets a github issue and goes thru a pull request approach. I've never been a real big fan of structured engineering approaches and my last boss, Taylor Williams, did a fantastic job of teaching us this and - he was right. Even on a small side project, there are definite benefits to solid, well defined workflow processes. One disadvantage when you work this way is that you end up with a lot of branches. And since branches tend to be named for the issue, it isn't always apparent the difference between say 444 and 445. When branches are transitory such as "fix this bug", that isn't a big deal. But when a branch is longer lived, because it just can't be completed in a short period of time, you are likely to simply forget the branch name. As an example, last Thursday night, I started work on a pretty complex enhancement and then a new bug came up Friday morning. My response was to do an add / commit and then change back to develop and create a new issue and fix that bug. And, somehow, between Friday morning and tonight, Monday night, the issue number has jumped by 30 issues (if you work this way then you make a lot of issues). So I went to find the branch and I simply couldn't. I was at 480 and I looked back at the Github Issues page and I thought it might have been 460 but that turned out not to be it. As I thought about it, I realized that I knew when I last worked on it, the preceding Thursday, and there had to be a way to to look at branches by date created. A bit of Internet research led me to the git reflog command: git reflog --date=local Here is an example of reflog's output: e95bf81 HEAD@{Fri Nov