DOC: Update dev workflow example - #10849

I'm confused why this is here (and in the original). If you do it later, when the work is ready, then github will give you a nice web link to copy & paste to do the PR.

Also, if you keep it here, I would keep the --set-upstream...

for what it's worth, I never manually say --set-upstream. Otherwise I agree that it might be better to push only once some work is done to get the github pop-up for opening the PR (maybe it also works when pushing for an existing branch?, I've never tried).

I never use --set-upstream. In fact, I think a plain old git push is dangerous (personal opinion) and prefer to be explicit when I do the push. If there is a strong preference to add it back, I will.

Sure, I can also delay git push till the end. I wasn't questioning why this tutorial was pushing so often.

oh, git push, just as is, is only asking for the troubles, I don't think should advocate for it anywhere.

I do use -u (I find I'm more likely to push to the wrong branch if I have to enter a name, even with auto-completion...), but for the dev workflow example, I agree it is better not to - keep things as simple as possible. And really it is only useful if one keeps on pushing. So, if you are up for it, I would remove the git push until after the user has done the testing. After all, the whole point of git is to enable asynchronous development - there is no reason to keep github in the loop.

@mhvk - I use gitprompt that decorates my bash prompt (there are way more fancy solutions, too, I just never got to the point of switching), so I always see which branch I'm at. It gives a very convenient double check for names, as well as branch status compared to upstream/origin. And I just got into the habit of double checking with a git gui whenever I need to force push to a branch (in those cases I usually just see the hash as normally I don't bother to create a branch when working with other people's forks).
Overall I find this a highly efficient, but also a quite safe setup.

I am not sure if we want to get in the weeds on setting up custom git prompt etc. But I did remove all the extraneous git push commands.

Oh, I'm not saying we should do anything about git prompt, it's on the same level of arbitrary personal preferences as the choice of editor. It was only a pointer to Marten's point that helps to avoid pushing to the wrong branch, in case he doesn't use it or something similar.

Ouch, this is quite bad!!! Doesn't even install things beforehand. I'd say this should be tox -e test -- -P coordinates...

Or, after all, suggest setting up with tox --develop.....

It should work to run pytest directly, but yeah for a first time contributor I would suggest tox, no develop etc.

Later in the tutorial we ask people to run pytest, we should have them install it here. You could argue for a [all,test] here if you want to be able to run the full suite.

@bsipocz This is my current leading theory for the issues the new astroquery contributor ran into fyi.

@mhvk's suggestion below to turn the pytest into a call to tox is way better. Although arguably we should have them install the test extra anyway.

This should really be:

or via tox.

I removed instructions to keep changing directories, so they all run from top-level now.