[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.

[JeremyNT]

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

I never work on a checked-out version of a branch that's currently being updated. I always check out a new branch for my work and rebase or merge off the branch others are working on.

I'm fully aware of stash, and every now and then I use it, but it's pretty infrequent. Seeing as you need to learn branching anyway it's not going to be important for every workflow.

[kubanczyk]

Exactly. For some busy repos I tend to remove local master (and develop) branches altogether. It's less moving parts that way.

    git branch feature1 origin/master   # create
    ...
    git fetch --all
    git rebase -i origin/master feature1

Also, use emacs's magit as a better ui. Even if you don't use emacs, seriously. It's fantastically easy and fast.

[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.

[wool_gather]

Tip, instead of amending, it's also straightforward to "uncommit" a temporary commit when you come back to it. `git reset HEAD~` and the state of the commit becomes the state of your working tree instead.

[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.

[pdimitar]

That's one more confusion vector. I for example use Git for like 10 years now and I didn't know about this option. It didn't even occur to me that it could exist.

So basically, I am proving the article's point.

[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)?

[simiones]

git fetch && git rebase origin/master, which is equivalent to git pull --rebase origin master, requires your worktree to be clean, so you must either commit or stash if you have any local changes.

[simfoo]

    git config rebase.autoStash true

[renox]

I think that's a very good way to have a long list of things stashed that you don't remember what they are. Commiting your changes is much better as you can add an explanation for your futur self.

[simfoo]

Well it does auto-pop the stash as well if the rebase was successful. I've been using it for ages and never noticed a growing stash

[OJFord]

Autostash

[simiones]

Ok, so you don't need to know git stash (good) but you need to know that autostash exists and how to configure it, so you still don't get away without an extra concept. I suppose the nice part about autostash is that it's easier for someone to just give you a .gitconfig with it, and not have to teach you how to use git stash.

[JoshTriplett]

You still need to know how to use git stash, in case the stash doesn't cleanly apply after the pull.

[OJFord]

The `.gitconfig` and also be 'given' to you by just being checked into the project. Someone has to know that you can have per-repo configs, but not everyone. ;)

[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?