Is anyone else getting tired of seeing all these "git tips", "cheatsheets", and "helpers" on here? While these all may look cool and be flashy, I've never used a single one that's showed up on the front page. Personally, I find the man pages + Google to be good enough. Then again, maybe I'm a curmudgeon.
You're not a curmudgeon, but I'll wager you've been using git for a while now. Here's the problem I have with git -- it has one of the worst CLIs I've ever seen. Many command names are counter-intuitive, i.e. they don't do anything that you would assume from the name alone. To make things worse, most commands can do rather different things depending on the command line switches.
This is all something that people can get used to, but the problem spills over from CLI into GUIs, because GUI authors try to make their programs more newbie-friendly and use more sane command names and lingo. As a result, no two GUIs will use exactly the same names for the same actions.
So imagine a newcomer to git, who starts using a GUI and gets used to its lingo. Unfortunately, that newcomer can't easily communicate with other people who use other GUIs or CLIs. Worse, sooner or later the newcomer will have to resort to using the CLI or a combination of different GUIs, because there's always some useful git feature that you either can't do in the GUI or is an order of magnitude easier to do from the command line.
That, in my not-so-humble opinion, is the worst problem with git. To me, this is sort of tragicomic, because git is absolutely the best VCS I've ever used.
As an author of a Git GUI, I've thought about this problem a lot. git-cola is quite user friendly, but its target audience is specifically power users (I wrote it for myself). I don't like dumbing things down for new users.
If you think about it -- targeting new users is not the ideal for a maker-centric tool. A master chef uses the sharpest knife around. The new chef is only new for so long before he graduates up.
Yes, yes you are because man pages are _terrible_ to read especially if you don't know what to even look for. I can see them being useful if you are already familiar with the product and just want to double check what a feature does; but as a newbie? Showing me the man pages would make me want to bail.
No I'm not tired of it at all. I think it is more than cool and flashy, as it does a great job of showing how changes move between each part of the repo. This is great for beginners. The man page and google is good enough, but this is a great addition.
Wow, this is actually good use of visualization. I clicked through expecting a one pager. Instead, I got an interactive cheatsheet showing how the commands interact across different repos, indices, and workspaces.
I'm actually of an opposing viewpoint about the visualization. It gets in the way of the information, why does this even need to be visualized and stylized? I know git is anything but stylish but this feels like visualization for the purpose of visualizing something.
I disagree. When I explained git (as best I could) to a friend I drew something similar, though less detailed, on the whiteboard. It helps to see the different spaces an the commands that push files between those spaces. I found the visualisation useful in this case.
I just gave up and use SourceTree. I don't like git's syntax at all, but have to work with it, so a nice GUI works best for me. Maybe I'm getting old, or maybe I just prefer a better designed command line interface (for my personal projects I'm using Fossil and am quite happy with the command line there.)
I found out about SourceTree after I had already learned the commands and it improved my productivity a ton, I can do everything faster with it and rarely use commands. It has so many features baked in it is amazing. Huge props to Atlassian for buying it and making it free. It is now my goto recommendation for anyone getting into Git.
I used to use SourceTree. I moved to using GitX: http://rowanj.github.io/gitx/ and seem to prefer it much more. SourceTree feels too cluttered. Gitx has better UX and appeals to me as someone that prefers to view more relevant content on the screen.
Using a GUI is a great way to get your feet wet. One challenge with git is simply getting an intuitive understanding of how parts of the system relate to each other. After some time in SourceTree, it is possible you'll start to appreciate the flexibility of the CLI and maybe even find a place for it in your workflow.
I understand Git quite well and I still only use the CLI for the rare actions the GUI doesn't allow, like deleting a remote branch or using reflog to find a commit that's no longer pointed to. I use Git Extensions on Windows, SourceTree on Mac. I have a slight preference for Git Extensions.
I am normally just a command line guy, but I really do prefer SourceTree for merging and moving/visualizing branches. And it makes it nice to add only hunks of a file.
I have to press the back button several times to get off of this site (after clicking on this site several times). Each time I press the back button, I am given no visual feedback from the site (unlike on wikipedia, where I am scrolled through the page as I press "back"). This page certainly does break the back button.
While that may technically be true, it's a problem because it violates user expectations. It makes sense that clicking a link on Wikipedia's contents section would update the URL, but I think it is much less clear that interacting with this page should change the URL for every click.
My awkward git use case: while working on a branch, I frequently want to merge changes from the (upstream, remote) master into my branch. Is there a faster way to do this than switch to master, pull, switch back, merge master?
Strictly speaking, you can pull from any remote branch directly:
git fetch remotename
git merge remotename/master
But you usually just want to rebase your changes onto the latest HEAD:
git fetch remotename
git rebase remotename/master
Merging will place the remote branch's changes after yours, which will make your history a nightmare, especially if you're going to continue working on your branch. Rebasing will place your local branch changes after the latest changes to the main branch.
Note that in this case, your remote tracking branches wont be updated, so git status will say you are ahead of the remote, while you are in fact at the same point.
A "git fetch <remote>" would then update the remote tracking branches.
If you are using topic branches, it's bad practice to merge from upstream when it is not necessary [1,2,3], because you clutter your branch with new features that are mostly unrelated to what you are trying to accomplish. Consider merging the specific topic branch that you need rather than 'master'. Alternatively, if nothing depends on your branch yet, you can rebase onto 'master', though this may invalidate earlier testing.
Now to your specific question (fast-forward a local branch without checking it out), you can
git fetch origin master:master
or
git push . origin/master:master
Then you can merge 'master' instead of 'origin/master', thus eliminating the remote URL or "remote-tracking" language from the prepared commit message.
Your posts seem to be arguing that you shouldn't be merging branches that are full of experimental crap into your topic branch, you should only merge releases - which I agree with (where I work we use the github-flow where the master branch tracks the release version).
I really like this because it shows the different 'places' things happen in Git arranged spatially, and groups commands into those spaces. This really helps with building mental model of how things work.
The visualization is great and a lot of fun but I would also like to have a non-interactive version for quick paper-based reference.
Great visualization. It actually shows how messy is git command line interface. Just looking at a cmd syntax it is hard to guess if the cmd refers to workspace, index or local repository.
This is pretty neat, but I find it pretty annoying that my eyes have to keep shifting up and down to read the explanation for each command. It would be nice if the explanation text popped up closer to where my eyes are already focused.
