How large or small (or how often) are the changes you make in a branch?
How large or small are your commits?
Do you push often?
My use case is - I think I should create a branch, do so, then wind up making changes unrelated to the reason I branched. Those little tweaks that you might as well do while you’re there, or you’ll forget. Merging is never a problem because I’m a one-person ‘shop’.
working and managing a team on a large-ish project (20+ devs) changes and commits can be both large and small, always often 
Managing a few open source projects, commits can be as small as one line to touching every file. It all depends on the work. Each commit is usually a complete piece of work (a bug fix, new feature, etc).
Often, especially when adding a new feature, I will add multiple commits over time into a branch, gradually building up the feature piece by piece. However, when I merge the new feature into master, it will get squashed into a single commit. That makes review of the individual pieces of the feature easier, as the feature comes together, but also groups all of the changes in the master branch to more easily see where a change came from.
Often, the best course is to do what your future self will want/need. In the future when you are looking back and don’t remember why you made a change, what will best help you remember? Over time, as you gain experience, this will become easier to do. Although, there will always be those things you could never anticipate. So don’t beat yourself up about it too much.
You mentioned you’re a one-person shop. Me too. So your git usage is neither here nor there. It’s good we use it, but we can develop our own workflows with it.
When I’ve had to come alongside a team, if that team has any git preferences, they’ve always made them clear.
As far as doing little things unrelated to your branch in git, I wouldn’t worry about it.
I managed a 30-strong developer teams --now I’m more into technology strategy consulting. From my perspective: frequent but, most important, atomic commits is one of the traits of seasoned developers.
For those “little tweaks” you mentioned, my suggestion would be to note it in your backlog and apply these changes after the feature branch has been merged.
If you’re a one person shop - why branch at all? Commit frequently and often. All commitments pass tests, all commits are clearly named.
I love
That is at the heart of true CI.
For a one-person shop, branching isn’t necessary, but it’s a good habit to build.
In your case, you say you created a branch for a particular reason, and then find other things to change.
An approach that I’ve used here is,
One could argue that as a single developer you don’t need branches. I follow that all feature work should be done on a branch and only when it is done, it merges to master. Master should always be “shippable”. A branch lets you evolve the work over multiple commits without fear of corrupting the master branch.
Thanks for the responses everyone!
I probably should have given some context. I’m doing research for my dissertation, so a lot of what I do is trying something that I thought of. Sometimes it’s good and if I’ve thought to branch, I merge that into main. Other times it’s a 
show, and I just leave it (in case there was a good thought in the code), and switch back to main.
What prompted my post was I got into a situation where some small-ish binary files were out of sync with origin/branch. I decided to abort, and lost all changes in source files too. Fortunately, I have Arq set to do a 5am ‘before I mess with it’ backup, so could recover.
This is interesting, and something I had feared doing, but not researched. Last week I had to go through several commits, picking and choosing different changes to make to main, while leaving behind the things that didn’t work. One would think ‘cherry picking’ would be exactly this, but nay, 'twas not to be.
I really need to read up more on git, github, gitlab, etc.
Still open to input, but, thanks @aardy , @waylan , @snelly , @pantulis , @mlevison , @scotte !
Of course I’ve seen this lots of times with Git. One of the tricks in my sleeve with other source control systems was to have my commited branches on separate different working copies on my hard drive. I used to do merging with Emacs diff-merge on a new working copy. Mind you, this was pre-subversion era.
Somehow the developer hivemind has lost that practice, because with Git it is not supposed to be necessary and you can work across commited changes and branches on the same local working copy. That is, until you shoot yourself on the foot with git!
Not gonna lie, I kind of miss rcs.
You could do things like:
#
# $Id: /home/john/src/myfile.h#3.14$
#
And have the version right in the source.
or
printf('Version $Revision: #3.14$\n');
I’m doing significant development now in 2 different IDEs on 5 separate software projects in 2 programming languages. I also use a GIT repo for documentation but that is a hot mess right now.
For 2 of my projects I have a master branch that is the (relatively) stable code that is at least working. I do all development in a development branch of my own and my husband does all his development in his branches. I control the merging. Often he just pulls down my latest and starts a new branch whenever he needs to work on something. We rarely work in the same modules or sections of code so rarely have conflicts. Usually it’s me causing them when I decide to take a break and do some code cleanup (remove excess print statements, delete spare newlines, compact and adjust comments and reformat queries or move entire sections of code around to make it more readable) If he’s made any changes in that area it can be interesting but I can easily pick out the version I want to use when I get the conflicts.
For 2 other projects Master is where all development is happening now and there are no branches. It’s also not working yet at all. I’m building the various modules and nothing will actually run yet. When I ge tthe first actual working app done I’ll leave it as master and start a development branch.
I have some commits that are adding 5 or 6 files or major changes to one or more files. I also have commits that are as simple as I’ve been working on the same issue for an hour, need to get up and go get something to drink so I’ll do a commit before I leave. I use commits like comand save from working in word processors. I usually also push to the GitLab repository at the same time just so I have an offsite copy. It’s been helpful as I can go back and recover things I screw up later.
It’s very rare that I don’t push each commit when I do it. Only times I can think of are when I had to rush out to deal with some sheep issue that I saw out the window. I’d do a quick commit command and head out the door. Push takes 2 more steps after the commit for me so in an emergency I didn’t want to wait to do them. I can commit with a hotkey, sure the commit message will suck but at least the code is saved.
My biggest issue is going back and forth between the languages. I start writing and get errors because I am working in one project and use the wrong language because I just was working in the other project.
One thing you can also do while experimenting is just clone the directory before you start messing with local branches. Or make a few copies, and push the changes from the one which approach worked out the best. It’s a little faster than reaching for the backup and it can be instructive to run different commands on the same state and see the difference.
I also recommend one of the visual git tools that are faithful to the git implementation and explain what they’re doing. I use Sublime Merge. You can just keep it open while you work in cli to see what’s happening, or work in it and then inspect the results in Terminal.
Also, you’ve surely seen this but reading part way through the git-scm.com book has helped everyone I’ve known who’s done it. Just stop when you feel the itch to try what you’ve learned. 
Yeah, if I’d known I was going to hose it, def would have. That’s one of the things I love about the APFS - I can clone a few gig folder in a few seconds, do something edgy, then delete the one I don’t need after.
I’ll have a look, thanks for the recommendation of Sublime Merge. I’m currently using Fork, after trying (what were they) Git-Kraken, and the flower-looking one that changed their licensing on me, and the Git one.
Yes, thanks for this reminder too, RTFM
Oh the fond memories of RCS for sure!
oh yes, I forgot to mention that I do all merges and rebasing etc in GitKraken just because that’s the one that was free and seems to work well for me.
For small projects only I will see, I don’t branch. For bigger projects that other people will see or collaborate on, I branch for each new feature/fix. If I find other tweaks to make that are unrelated, I usually create another branch off of the main one and make them there. Unless they’re tiny, in which case I’ll just make them in-place.
I use medium-sized commits although I’ve been trying to get into the habit of smaller, more frequent ones.
No please, this is the most dangerous. Branch and PR.
I don’t think we’ve talked about Issues.
I use them extensively - on my essentially-one-man open source projects.
But I can’t claim all enhancements or fixes are as a result of a GitHub Issue. Some just happen. Oops.
The real, ahem, issue with Issues is getting them into OmniFocus. It seems the method of GitHub Notification via IFTTT is somewhat fraught. It helped a little when I added PushCut into the mix.
So I have weekly OmniFocus tasks for each project to sync up the Issues. That way I have a task with the URL of the Issue for each open Issue.
(Capitalisation of “Issue” deliberate - in the hope it airs readability.)
I’m interested in that. I’ve struggled with several versions of tracking things I want to do both bugs and enhancements.
Fisrt try was to use just flat files by program module with the bugs in one section and enhancements in another. Failed due to too many places to look for stuff and not enough space to easily track all the ins and outs of what I wanted to do or fix.
Second try using a Scrivener document with te corkboard as a poor woman’s kanban style tracking system and then the files had the details. Failed due to not integrated with my workflow.
Third try being tested is large lists of issues/enhancements as notes in Obsidian with an Obsidian kanban for the ones I am working on and linked into notes with details of those. Not yet successful or failed. Still testing. There is a request to hav this integrate with Github/GitLab issues somehow.
I’ve tried to integrate the software development work with Omnifocus and failed no matter what I’ve tried. My projects in Omnifocus related to the programming are all things like investigate some tool or package I might use. Like Investigate licensing for PyPedal for inclusion in AnimalTrakker Population Genetics Module. Or Decide whether to store links to DNA fastq files and how to categorize the sequencing technology used in the database. Or my current next action, Decide best way to store user privacy preferences of what personal and animal info can be public and what is restricted.
So Omnifocus holds more research stuff not actual coding implementations or issues.
Why is this dangerous? I’m curious.
Oddly in my professional work (Agile Coaching, Training and Consulting) - I help people move away from long lived branches. See: Branching Strategies in Source Control | Agile Pain Relief Consulting