Using git and a workflow where I have many loose changes that are not intended for check-in. Is there a good git way to manage those not-for-check-in modified files?

In my project, we have about 700,000 source files. I'd call it a larger project.

When I am working on fixing a bug or implementing a feature, I will quite frequently end up with many files that I have made ancillary edits. Such as debugging instrumentation, or alternative implementation, or an expensive check for a never-happen situation that once appears to have happened in the wild and I want to catch it if it ever happens on my machine, or clang-format because the original had goofy formatting.

To commit my good changes, I'll branch, I carefully add the relevant files and commit those. (Followed by a push of my changes. Make a PR. Get code review approval. Jenkins builds on all the dozen different target platforms, and runs the test suite. Then I merge my branch into main.)

Probably a fairly typical workflow... except for that I have many (1000 ) not-for-check-in files that I want to keep modified in my worktree, but not merge those into main. That latter part is probably atypical.

With Perforce, I would add my not-for-check-in files into a not-for-check-in changelist and park them there. They'd be out of the way, and I could not accidentally pull one of those "tainted" files without taking steps to move it out of the not-for-check-in changelist.

So far, my git tactic of being super-duper careful has worked, but seems fraught with peril. I maintain a stash.txt file that has a list of my not-for-check-in files, and frequently stash them to temporarily get them out of the way, do my git things (making branches, fetch, merge, push, whatever), and stash pop them back in my worktree. Seems janky, manual, and error prone; high cognitive load. Has to be a better way.

(I have not run into the scenario when I have a single file that has both good changes and not-for-check-in changes. If/when I do, I am aware of how to add-and-commit hunks of changes.)

I have tried the tactic of making a branch, add-and-commit both my good changes and not-for-check-in changes. Then cherry pick the good changes for what should go into main. That scales poorly with the 1000s of not-for-check-in files that need to be sifted through.

Any advice or guidance is appreciated.

CodePudding user response：

Frame challenge: this is not a git problem, but an application architecture problem.

Leaving a large number of changes uncommitted in your working tree means:

• they are probably not backed up anywhere; if your development machine suffers a fault tomorrow, you will lose all this work you've been carefully preserving
• nobody but you is getting the benefit from them; quite possibly your colleagues are wasting time making the same changes over again
• the version of the application you're working on is gradually diverging from the one actually deployed to production

Let's look at the example changes you mention:

• debugging instrumentation - commit it behind a "development-mode only" flag, a set of debugging feature flags, or improve your debug tooling so that it's not necessary (e.g. you rarely need "dump and die" statements when you have a working interactive debugger)
• alternative implementation - should be on its own branch until it is ready; or committed behind a "prototype" feature flag so that you can turn it off to reproduce live behaviour
• an expensive check for a never-happen situation that once appears to have happened in the wild and I want to catch it if it ever happens on my machine - again, an ideal use for a feature flag
• clang-format because the original had goofy formatting - just commit it, and everyone will thank you in the long term

CodePudding user response：

Using git worktree, I would work with two separate working tree (from the same cloned repository: no need to clone twice)

• one for the work in progress, with many files not to be added
• one for reporting the work which needs to be added: no stash to maintain in this one.

Does Git support multiple concurrent index (or staging), which would be the analog to Perforce changelist?

Not really: it would be easier to make multiple commits:

• one your PR
• one for the rest

And push only the first commit (for PR).

From the discussion:

• "How can I make Git "forget" about a file that was tracked, but is now in .gitignore?" uses git update-index --skip-worktree, which I don't find very practical, or easier than git stash.

• git rebase -i follwoed by git push <theRightSHA>:<PRBranch> should be enough