See, switches in git are there because git maintains backward compatibility.

Switches are there because git commands tend to greatly leak the abstraction and group behaviour in terms of the underlying plumbing, and because Git maintainers most likely would rather add new switches to existing commands than new commands intersecting with existing ones.

Sometimes a switch really would logically be better as a whole new command.

Which could trivially be done without BC issues and thus can't be an explanation why existing commands keep growing new switches.

This article is a great way to find those hidden things.

It would have been a useful article if it had been about showcasing interesting or useful git switches.

Alternatively, read the documentation and know how to use your tools instead of reading blog posts that lists a few things one person has found useful.

Agreed - these aren't lesser known git commands at all.

The switches given to git commands in the article might be lesser-known, but title could be clearer that this is:

    > Some suggestions for git aliases

I should really read more of the git doc but at least I learned about aliasing in the gitconfig from this even if, I too, was expecting actual git commands

The Fucking Article's Author.

"commend" seems especially bad, it's both unclear and longer than "amend" would be.

My aliases list is pretty small, aside from amend I have

* get (pull --ff-only --all -p), basically a hard sync with all remotes, updating the current branch if there are no conflicts or divergences

* summary (log --oneline --no-merges), given a range from git fetch/pull, provides an overview of the commits you just fetched

* original (!git show $(cat .git/rebase-apply/original-commit)) during a rebase conflict, shows the original commit whose application failed (it can be difficult to untangle a rebase conflict, this sometimes helps a lot)

It make me think of pirates drinking their grog.

I would have named it "git rum"

I like the `git grog` command, I might actually use that.

The idea of `git please` is not bad but it made me wonder if it could be possible to go even further.. a variant on --force that only force-pushes IF NOT ONE HAS PULLED YET.

I can see why this wouldn't be built into git core however, as it's quite stateful and depends on tracking other people's fetches, which probably isn't easy.

Well, if you think of yourself of the ruler of the repo and "pushing down" to the plebs, it makes sense ;)

I love the implication that the upstream repo is the enemy, so you mentally put it down. Way to go Ender.

Well git up is a literal translation of what svn up does. git down is just funny. Being a child of the early 80s, I guess it makes me think of this awful old school rap:

https://www.youtube.com/watch?v=OwU32Fa_Mko

I would name them "down" and "up" instead.

Years ago... I was a pretty prolific svn user. Coming from svn, I knew that it would fetch changes from the central server (remote in git parlance) and then rebase them with whatever you had in your local tree. This is where git up came from, literally an equivalent of svn up.

Well, admittedly my current situation lends itself well to 'worktree' where normally a stash is probably just fine.

At the moment I'm doing a big rework (porting our software from a 10 year-old OS to CentOS 7), so I have many, many modified files (all tiny mods to fix new compiler warnings from new toolchains) and untracked and obsoleted files.

Basically, it's too much for me to keep track of if I change anything, so it's a case of "whatever you do, don't touch" that pushes me toward the worktree solution.

I've been pulled in to work on customer escalations on released code (one instance from 2 releases ago), so it's just easier for me to create a whole new worktree.

I imagine that once I'm back into a normal dev cycle that I'll be back to stashing.

I would name them the other way around since I'm pulling "down" and pushing "up" ....

same functionality, my alias is "rush"

$ git rush

I have up aliased to

  pull --rebase --stat

That gives me an idea of what has changed, Though I often follow with:

  git log @\{1\}..

I just usually do something silly like 'git add . && git stash', i had no idea it was built in...

I use a very similar version of this, and people are often surprised that I'm working directly on master. Well, when it's ready to go, `git checkout -b feature/name; git push origin HEAD; git resync`.

Rebasing the root commit has been possible for a while using `git rebase --root`.

http://stackoverflow.com/questions/30277149/how-to-use-inter... goes into more detail.

There's also the `--root` flag for rebase, which solves this problem without needing the dummy commit. I think this section of the article is out of date.

I actually like to make an empty root commit just as a place to describe what I intend to do with a repo. I'm uncomfortable doing it as a README commit because that lends it an undue amount of permanence once work begins.

Occasionally on repos that are really just for me I even do this as a 'root' commit for work branches, but the way rebase rolls over empty commits makes that kind of problematic in the long run.

It also helps if you want to do an octopus merge of branches that otherwise have no common ancestor. If it comes to it, you can use git replace to provide a false parent for the root commit.

I'm not a git expert (yet), but I agree. I've read the stash man page a few times and tried to imagine when I'd want to use it over the alternatives, but I never do.

Or even just branch, commit, rebase onto the desired branch.

git checkout -- .

Also works well for this use case

Doesn't do the same thing, without some more options. Stash is shorter.

Now here's one I actually like. As an alternative to git reset, a git stash is safer, and gives you an easier way than reflog to recover if you dropped a commit you want back.

For one of my projects, the 'build process' requires that I use the git archive command (basically archive to .tar.gz without any git-related files/directories). git archive on its own is fine for final builds because it's based off of HEAD for the current branch, but if I want to test a build with working changes, I would either need to commit all the changes _or_ use git stash and then archive based on the state I just stashed.

So in this case git stash works a lot better for a 'temporary' commit, kind of deal.

It might not be optimal but I've found the process to work pretty well for this particular project's situation.

and make sure to patch up the upstream reference

`git sprout <branch-name>` looks identical to `git checkout -b <branch-name>`.

You're right of course, but whereas for a lot of purposes I understand the impulse of "I don't have time to learn this". For so many things that's the right call, but for a developer using git I would like to insert the brain worm that maybe it isn't.

I consider git to be on the short list of career-long tools. The rest of the list is linux, bash and vim. Knowledge of these things has a long half life and will serve me across jobs. Even a language I've used for 10+ years in my daily work like Ruby is more likely to become obsolete within my career than git. And the thought of using git without understanding reflog is anxiety producing. The beauty of git is not in memorizing its arcane syntax, it's in understanding the elegant data model.

That's my case for why every developer should at least know git-reflog. git-fsck I have to admit never having used :)

personally I rarely stash and often it's just to get rid of a bunch of crap. rather than googling reset --hardhatheadhenry, I stash and drop.

Total hack I know, but whatever.

Committing your entire working copy to a separate branch can work just like a safe stash:

    $ git branch
      master
    * cool-feature-1
    $ git checkout -b stash-2016.09.30T01.10
    $ git add -A; git commit -m "stashing WIP for later; maybe add some commentary to remind myself what I'm doing"
    $ git branch
      master
      cool-feature-1
    * stash-2016.09.30T01.10
    $ git checkout master
    $ git branch
    * master
      cool-feature-1
      stash-2016.09.30T01.10
    # do other things
    # later...
    $ git checkout cool-feature-1
    $ git merge --no-commit --no-ff stash-2016.09.30T01.10
    Automatic merge went well; stopped before committing as requested
    $ git reset
    $ git status
    On branch cool-feature-1
    Untracked files:
     ...

And now your old WIP is back, ready to keep working, and in the meantime you could have pushed up your "stash" to a remote and grabbed it back.

There might be something terribly wrong with this, but if there's not, then I don't understand why git stash doesn't do something similar to this by default.

I use stash in one of the two workflows below, neither of which have ever caused problems. Stash's advantage is in not needing to create branches, commit, or un-commit the code back into your working copy. Very quick, and I've never had problems.

- Paired operations `git stash` / `git stash pop` to quickly get rid of everything then reapply it a few minutes later.

- Stash as a "I probably don't want this code, but may as well keep a stashed copy" alternative to a hard reset. These stashes all then show up in my SourceTree sidebar to easily peruse or apply if needed (or copy/paste individual lines). Not a big deal if lost.

If I'm actually backing up code that I'll likely use, or need a remote backup of my current working copy to protect against laptop theft or HDD failure, I'll branch/commit/push the backup. Then use a mixed reset later to get rid of the commit itself and return everything to the working copy.

there's no sense arguing. to many git users I have met, the software isn't the product, the git repository is. I have met someone who will happily spend an entire day refactoring all the commit boundaries by teasing apart and combining diffs so that they match some retroactive narrative that looks prettier.

you must be one of those squash haters

That's a good example of what I'd consider to be a mildly unsafe use of stash, since if anything goes wrong you can lose unsaved changes. It's easier to forget what you're doing if you have merge conflicts during your rebase, or end up stashing something else while you rebase.

The safer alternative workflow is:

  git commit -am "WIP"           # Just throw your uncommitted changes into a commit
  git rebase -i origin/master    # you might want to checkout my git rearrange command above
  git reset --soft HEAD^         # now un-stage your uncommitted changes and keep working

The advantage of this is getting your uncommitted changes into a commit that can be easily recovered if anything goes wrong. Even though you get rid of the commit, this process is all stored in the reflog, and you can undo any of it easily and without resorting to fsck.

You might check out "git rebase --autostash" if you haven't already.

Or even better than patch, git apply.

Ha! You're right, that's silly, thanks! I didn't even notice. I don't remember why, it's been a long time, but I think I had a tricky pipe command to figure out the upstream branch-point a long time ago before I learned about merge-base and @{u}.

Hmm, maybe you're right. I don't know anymore. I thought it just prefixed aliases with "git " and otherwise ran them as normal, but I admit I haven't researched this topic in a long time.

Stashing is great

Because some things are only possible while there are no changes. (I changed this one-off file for testing or debugging something, need to pull latest changes, so I stash)

Stashing comes from a tool called quilt https://savannah.nongnu.org/projects/quilt

My IDE stashes things behind the scenes quite often, allowing me to do many operations on "dirty" workspaces.

Do people really use stash for things they value longer than a few minutes?

You'd be surprised. ;) Even a few minutes can get you into trouble though. The very last person I helped out of a stash crisis two days ago did exactly what you outlined, fully intending to stash pop immediately, and couldn't find his change and panicked.

What actually happened was he'd unknowingly stashed again during his branch switch, and his first stash was there, but not on the top of the stack. GitHub desktop was auto-stashing or something. (GitHub desktop has made several very strange choices...) Anyway when my friend applied an empty stash, he thought he'd lost his changes. He called for help on a Saturday, and I tried to point him in the right direction over email, but by the time I got to a terminal to see what happened, he'd already rewritten most of his change, having decided it was a loss.

OK, FWIW here are some safer alternatives to switching branches without stash:

- First thing to know is that you can switch branches with uncommitted changes in your working tree. You don't have to do anything else, git will protect against conflicts, so why not always try this first? It's less work most of the time.

If git complains, you can:

  git commit -am "WIP for the_correct_branch"
  git checkout the_correct_branch
  git cherry-pick my_old_branch
  git reset --soft HEAD^  # Optional, if you want to unstage
  ... Later ...
  git checkout my_old_branch
  git log
  ... Notice the leftover commit ...
  git reset --hard HEAD^

Or here's an alternative that doesn't leave the dangling commit for later:

  git commit -am "WIP"
  git branch work         # you can always do this with uncommitted changes
  git reset --hard HEAD^  # still on my_old_branch here
  git checkout the_correct_branch
  git cherry-pick work
  git branch -d work

If anything goes wrong with these workflows, my changes have been dropped in two branches, they'll be easy to find in the reflog, and the gc timer doesn't even start yet because they're still referenced. It's really hard to lose the changes this way.

The only option with the stash flow if the stash gets lost while switching branches is to use fsck, and the gc timer starts immediately because the stash is not referenced.

I mention the gc timer because some of the accidents I've seen are people popping stashes and only realizing later that they popped a different change than they thought they did.

They way this happens is people who are beginners to git. Once you know git, it's hard to imagine popping the wrong stash and not knowing it, but I've seen it happen multiple times. This is why I advise everyone to avoid stash - for beginners, it looks deceptively and attractively simple, but is easy to get in hot water. It's also another git subsystem to learn, as if git wasn't hard enough to learn. For git experts, it's so easy to avoid using stash, there are always safer alternatives.

I tend to stash debug code, so for example I'm working on a feature, and while developing I've added a bunch of console.log()s (or pprint.pprint()s, print_r()s, whatever). Then I can do:

    git add --patch  # include only the code I want comitted
    git stash --keep-index
    # now I can do some tests without my debug cruft
    git commit

And then ship the feature to staging/production, if there are any remaining issues with it I still have my debug cruft in the stash. It's rarely needed, so I don't want the overhead of a branch for it. If I lose it it's also easy enough to just add the debug code I need at that moment in case the stash was cleared.

One of the hardest thing about git is the multitude of options and workflows. It makes it powerful but also intimidating for newbies - so many commands and flags!

Having several years of git experience, I've set up on the following workflow, which avoids stashing and mixed resets. I think it's quite safe and simple.

1. using feature branches for everything (except when I'm the only developer in a given repo); I have `goto` and `forkto` and aliases for git checkout / git checkout -b

2. frequent, small commits - for backups, and to have "recovery point" for this scenario when you change one line and everything's on fire and you can't find out what's going on for next one hour

3. try to never do partial commits, always commit everything ( git add -A . && git commit ). This teaches you a discipline to do one thing at a time. If you have a sudden need to do something else, git branch, git commit, git checkout previous-branch. Or git commit, continue working, git rebase -i to reorder/squash commits later if needed.

4. for "work in progress, will come back later" commit I have an alias "wip" = "git commit -A . -m 'wip'"

5. for permanently throwing away stuff, "git reset --hard" (used rarely)

6. since I do lots of small commits, at the end of development I clean up with `git rebase -i`, squash stuff, improve commit messages if needed, maybe reorder etc.

Due to 2 and 3 I basically don't use stash at all. I think however not everyone is so keen on interactive rebase as much as I do :)

I find feature branches only useful for pull requests

I wasn't super clear in my top post, sorry. Mentioned a couple times in the thread, but as an alternative to a single stash, I would normally commit, not branch. Consider whether a WIP commit is that much easier than a stash, given that a commit is harder to lose.

I mentioned branches because that's the alternative to a multi-stash workflow, or to having a large time gap with a lot of work in-between stash & pop. Otherwise, my question is how much harder, really, is git commit & git reset --soft, compared to git stash & git stash pop?

Then don't ever use those commands. I don't.

That seems like a great way to use stash safely. A couple others here mentioned using stash as an alternative to git reset. I'm in favor of that kind of stash usage, it's even safer & easer than losing something to a premature reset.

I have more than 400 stashes… it turns out it's quite often that I find my current approach completely wrong and want to do a hard reset. But I don't do a hard reset but I stash it so during my next attempt I can still see it.

yeah, I find myself more doing a local commit with message WIP. I switch branches to do something else, come back, look at the log and if WIP, roll back the last commit

Directory hard-links?

This is how you have to deal with branching in almost every scm. Changing branch might require you to rebuild something slow and then it's good to have multiple working directories. If you have monorepos you might also want to test component a on branch x vs component b on branch y etc.

If you are only working serially then switching branch in one working dir is obviously easier and to be preferred but some times you really need multiple checkouts of the same repo.

Thank you for explaining this! I didn't know that and will start incorporating that into my workflow :) thanks for teaching me something new!

If code is important enough to me that I care whether or not I lose it, I commit and push.

I prefer to commit discrete change sets (not features, or stories, just a discrete set of changes that achieve a piece of what I am wanting, dont break the code base and dont break the build).

I have heard that phrase, I live by it and encourage others to do the same. it is especially important when working as a part of a bigger team on the same area of the code.

Teams that commit early and often are happy teams :)

OTOH I use stash constantly, multiple times every day, when switching between branches, because sometimes its just handy to be able to put stuff aside to look at something else.

I dont recall ever losing code because of it, but it is certainly possible and its not hard to see how it could happen.

Heres one I like to use sdiff = diff --ignore-space-change

If in doubt, the long one (git staaash) will always restore your worktree to what looks like a fresh clone of your repository.

Not necessarily. This depends on what branch you're on as well as whether or not it's up to date with the remote.

One reason I like git so much is that right there. The author is interested in reasoning about what branch certain changes came from, but I have to wonder why. Once changes are squashed and ff-merged, it's pretty clear where they came from.

Can't believe I just learned about rebase.autoStash! That is super handy.

That would prevent merging a second repository into the first in its entirity.

Yeah, I imagine it's unsafe because "git pull" implicitly creates a merge commit when it can't otherwise update, and your remote URL might now be pointing at a different history. Maybe github.com/someproject/somecode got replaced by a clean rewrite and you're actually looking for someproject/somecode-old. Maybe you were pointing at an unofficial git-svn import and now there's an official git migration. And so forth.

(Personally, I think the right way to address this is for "git pull" not to implicitly create merge commits...)

The first commit of a repository can not be rebased like regular commits

That's not necessarily true. This can be done with:

  git rebase -i --root

This doesn't even look like I wrote it, but I thought I did and use it all the time: "What was that (private) branch I worked on a few weeks ago?"

Just put this shell script in /usr/local/bin or wherever as "git-branch-dates"

  git branch-dates
  #!/bin/bash

  for k in `git branch|perl -pe s/^..//`;do echo -e `git show --pretty=format:"%Cgreen%ci %Cblue%cr%Creset" $k|head -n 1`\\t$k;done|sort -r

A couple of aliases I use all the time:

    [alias]
        graph = log --oneline --decorate --graph --all
        copy-logs-since = !git log --reverse --format=%B "$1".. | pbcopy

`graph` is similar to `grog` in the article. `git copy-logs-since <tag>` copies log messages since the tag, which I use for release notes. Very handy.

English isn't my 1st language either, but the power of downvotes is misused a lot on the internet, especially when there's no public trail who downvoted. Advise and canon may just carry too strong of a meaning for those who grew up in English-speaking school systems.

While it will end up being a little longer, these can all be defined as aliases within git (see https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases). Some users might prefer the aliases there rather than in their shell configuration.

I like "git ready":

    ready = !git checkout master && git fetch -p && git merge --ff-only

The use case is for when you're done with a particular feature branch and ready to start something new. It puts you back on master and updates it in a safe way.

git config --global alias.stache stash

You baitin... how is a lesser known git command a git alias?

Author's "commend" function I just call "cane"

git (c)ommit --(a)mend --(n)o-(e)dit

nitpick: I don't think you need --no-track in `branch --merged` as no branch is being created with that command.

    git diff origin/master -- test.file

It will show you a diff of a file between the master branch of remote origin and your local branch. I use it way more than I can think of.

  alias such=git
  alias very=git
  alias wow='git status' 

  $ wow
  $ such commit
  $ very push

https://twitter.com/chris__martin/status/420992421673988096?...

Some of my aliases, first some basic shortcuts:

  freshen = commit --amend --no-edit --date=now
  cont = rebase --continue
  br = branch --column
  recent = branch --sort=committerdate
  idiff = diff --cached
  ff = merge --ff-only
  co = checkout

Show what's left to do in an interactive rebase:

  todo = !cat `git rev-parse --git-dir`/rebase-merge/git-rebase-todo

Set tracking to to origin/<the same branch name>

  upstream = !zsh -c 'git branch --set-upstream-to=origin/$(git symbolic-ref --short HEAD) $(git symbolic-ref --short HEAD)'

I use this to swap my work to home e-mail or vice-versa if I've got it wrong. Need to specify an initial commit.

  allmine = filter-branch --env-filter 'GIT_COMMITTER_EMAIL=my@email.com GIT_AUTHOR_EMAIL=my@email.com'

  vim = "!gvim `git ls-files -m`"

It depends what you're using it for. Many people use Windows every day without knowing things like how to remap a network drive--but it's nice to have it there when you need it.

If you're by yourself and just need to keep a linear history all you need is 'git init' 'git add' and 'git commit'--if that's all you ever need, svn or any version control should work about equally well. But if you do need remote repositories, branches, rewriting your history, or commit hooks, it's there waiting if you're using git.

I feel like most of the different version control systems differ on those advanced features or how it scales for special needs. Git is great for decentralized and remote work, Perforce is better at handling histories with large binary files, etc. The basic features are fairly similar between them. Maybe there's a gui you like or a specific workflow, but I feel like that's a subjective choice.

git commend quietly tacks any staged files onto the last commit you created, re-using your existing commit message. So as long as you haven’t pushed yet, no-one will be the wiser.

Well, they might notice that the author and committer dates don't match, but you can add "--reset-author" to really make this undetectable.

    [alias]
      pull = push
      push = pull

:)

For every repo I fork I usually add a remote named upstream pointing to the original.

So then, whenever I need to get my copy up to date with upstream it's:

    update = !git fetch upstream && git merge upstream/master'

It's probably easily changed to make the branch configurable, but I have only ever needed this with master.

Nice list! I'll adapt some for my git workflow.

Here's some that I've created or collected over the years, in case anyone finds this useful:

https://github.com/randombk/randombk-dotfiles/blob/master/ma...

My two favourite aliases :

    mo = ls-files -m
    lol = log --oneline --decorate --graph

`git mo tests/` gets you modified files for the tests folder.

`git lol` I think as the command line version of gitk