[masonhensley]

Based on my experience - most teams will get by with ivanhoe's list.

You additional items are definitely helpful - but the typical team member's workflow won't cross those bridges. Team leads perhaps.

There's definitely levels of proficiency, but for a junior or even mid-level dev doing feature work, I think there red flags if they are needing to jump into stash, cherry, etc on a daily basis.

[simiones]

As I said to the other commenter - I don't even know how to use git without the stash, since you need everytime when you have some local changes but want to pull from the remote - the only alternative I know of is committing your local changes instead of stashing them.

Also, git lfs and git submodules and their associated commands are necessary or not based on the project, not on your personal level of proficiency.

I also don't know of any workflow where you don't need to look at the log at least once every few days, even as a junior dev, to confirm if a bug is fixed in a build or not if for no other reason.

[bntyhntr]

At work I have 30 stashed things some of which go back 2 or 3 years. I got distracted when I pull and forget to pop sometimes, or I was working on something so trivial I never unstashed it.

That doesn't seem great... Usually these days I try to put my temporary work on a temp commit or branch at least so I don't lose it to the stash. I'm not saying I'm stashing properly, just that stash is easy to mess up.

Also probably half of these are things I popped but had merge conflicts or something. I fixed the merge conflict why is it still there? (I know the reason, but still).

[chokolad]

> As I said to the other commenter - I don't even know how to use git without the stash, since you need everytime when you have some local changes but want to pull from the remote - the only alternative I know of is committing your local changes instead of stashing them.

I usually do all the work in branches anyways, so I'll just create a quick branch and commit it there.

[lhnz]

I've used both but generally don't use stash. I think it's more expressive to have a single commit like "wip: some simple description goes here" and then to `git commit --amend` this until we are happy with its contents.

As well as being more descriptive if you come back after a long weekend, this also means that you can swap branches without worrying that your stash relates to a particular branch but doesn't explicitly belong to this.

[kelnos]

You can set `merge.autostash` and/or `rebase.autostash` to `true` in your global git config and then you can `git pull` with a dirty working tree.

Of course, to the point of this thread, that is yet another concept you have to understand to get a sane working environment. I assume autostash is disabled by default because the post-merge/rebase unstash could result merge conflicts and be a pain to unwind if you change your mind. If you just blindly set this option based on someone else's recommendation without knowing what the stash is, and things go wrong, you'll require a mental model of the steps involved to fix it, which you won't have.

[anotherNae]

It might help creating patches for the dirty state with something like `git diff > feature.patch` and then drop the current changes. After update, it's another `git apply feature.patch` to restore the changes. This helps with remembering what each change means since `git stash show` is rather awful. YMMV

[kernelbugs]

Could you not perhaps git fetch && git rebase origin/master (for instance, to pull remote changes into a local development branch)?

[OJFord]

Autostash

[studius]

> I think there red flags if they are needing to jump into stash, cherry, etc on a daily basis.

Without stash, things can be nasty. Some alternatives:

1. Commit frequently, one tested piece of code at a time.

I'm sure this is what you meant. Not every environment and process allows this and not every change is small.

If you can though and have time, do this. If needed perhaps you can combine things and rebase later into larger commits. This is the reliable and clean process of development that everyone would love to have as a base, and then to do whatever they feel with it and it always stay like this with hard work and dedication.

Let's move on because that isn't always going to be the case.

2. Commit unfinished/non-working code.

The best analogy of this is like leaving unfinished crap all over the place that might look finished to some. At some point, it may go wrong. If you do this, you might name the branch with something standard indicating it's unfinished.

This always seems to happen when a developer leaves for a holiday/vacation or leaves permanently. Then some other developer tries to build/test it, it works, they smooth some rough edges and commit it. In my experience, it is was truly unfinished, the quality may end up being somewhere between a point on a line anywhere below the initial committer's typically code quality and anywhere below the fixer's code quality. There are exceptions, but as a general rule, be more careful with such commits if the personal investment and sense of ownership is not strong in that code.

3. Multiple copies of the repo.

It's likely going to be less efficient to have multiple copies of the repo from a storage standpoint.

Showing the stashes may be more efficient than searching through different versions of the files in copies of the repo or having to recursively diff repo copies.

Using multiple copies of the repo may also increase the chance of things going wrong or history being lost.

I still would recommend having a backup of anything really important in the repo at times, if you're not feeling confident or are worried about losing anything.

4. Throw away code changes.

Every time you switch priorities, you could throw away all of the work you had locally. If it was crap, this might be best. Be careful; you could lose something important.

5. Manually copy changed files to another area outside of the repo to ensure it doesn't get stomped accidentally.

This can be messy, but with tools to make it easier, it might be "ok". Compared to git stash though, it's likely less efficient, because whole files are being copied instead of just the changes.

6. Manually backup only the diff/patch files of changes.

Well, now you're just recreating git stash functionality, but sure, you could do that. People did this before git stash and still do. Create patch files. It doesn't sound as easy or clean, and you've got to put those patch files somewhere. Will that be consistent between developers? If a developer leaves or is unavailable, where would you find them?