I think that while Git would be great as a library, as a front-facing program it's UX could do an improvement:<p>A good UX is simple things should be simple, but complicated things should be possible, but now look at the following "basic" git workflow:<p>1. Add. I want git to track this file. Yes, sometimes I need to add certain lines, files, etc. Keep git add, commit, and push. But have a "git update" or something for beginners (and for 99% of use)<p>2. History - How can I go through a file to see its history? "git show REV"? What if I want a wikipedia style history? What if I want to go through the history of a file? There should be something like "git history main.c"<p>3. Undelete file - This is fairly common, yet, the command is<p>git checkout $(git rev-list -n 1 HEAD -- "$file")^ -- "$file"<p>A command like git undelete $file would probably make life easier.<p>I haven't gotten to the more complex workflow, and I definitely agree that git is a great revision system, but UX improvements can help<p>---
EDIT,<p>Mandatory xkcd<p><a href="https://xkcd.com/1597/" rel="nofollow">https://xkcd.com/1597/</a>
I'm going to describe a small issue I've been having with Git that I've tried Googling for in the past but have never found a solution.<p>I use a custom `git log` alias that prints out a nicely colored commit graph.<p><pre><code> [alias]
lg = log --graph --abbrev-commit --decorate --date=relative --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all -n 15
</code></pre>
The issue is that this includes everyone else's branches that have been pushed to origin. I only want to see the history for local branches. (I guess I'd also want to be able to see origin/master, but I recognize that there's nothing distinguishing that from the other branches on origin I don't want to see.)<p>I think the issue is that I run `git pull --prune` to get rid of any remote branches that have been deleted. I usually do this after I pull master, so I think I should just be running `git pull origin master --prune` as a single command.
A version control system should be simple. Engineers should be able to focus on getting things to work/done, not battling with a complicated, confusing version control system.<p>Most engineers should be performing two operations/two command s the vast majority of the time:<p>check-in <latest change>
check-out <latest version> or <last good version><p>If a file is new, check-in should ask you if you want to add it to the project.<p>That should be it.<p>The proliferation of tutorials, cheat sheets, books, front end user interfaces like SourceTree for Git is a symptom of a problem.<p>KISS (Keep It Simple Stupid)
I always give this interactive cheatsheet [1] to git newbies to help them conceptualize the state transfer.<p>[1] <a href="http://ndpsoftware.com/git-cheatsheet.html" rel="nofollow">http://ndpsoftware.com/git-cheatsheet.html</a>
My favourite remains Zack Rusin's, from 9 years ago. The state graph was pretty useful as I was learning:<p><a href="http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html" rel="nofollow">http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html</a>
My more intermediate-level cheat sheet: <a href="https://gingkoapp.com/git-notes" rel="nofollow">https://gingkoapp.com/git-notes</a>
Not as organized as the above two, but having being able to access it from the commandline beats anything:<p>[1] Client: <a href="https://github.com/evidanary/grepg-python" rel="nofollow">https://github.com/evidanary/grepg-python</a>
[2] Cheat Sheet: <a href="https://greppage.com/evidanary/5" rel="nofollow">https://greppage.com/evidanary/5</a>
I'm also maintaining a small Git cheat sheet. It's my personal list of stuff that I always find useful but can never remember how to type.<p>Let me know if you find it useful!<p><a href="https://gist.github.com/mplewis/a7563c7cb589048a071b" rel="nofollow">https://gist.github.com/mplewis/a7563c7cb589048a071b</a>
Don't like how it is based around merges. Cherry-pick workflow is so much simpler and provides clean history. "No merges" was the policy in every project I worked.