Git is hard: screwing up is easy, and figuring out how to fix your mistakes is fucking impossible. Git documentation has this chicken and egg problem where you can’t search for how to get yourself out of a mess, unless you already know the name of the thing you need to know about in order to fix your problem.
So here are some bad situations I’ve gotten myself into, and how I eventually got myself out of them in plain english*.
The downright luxurious Git client. Cross-platform, 100% standalone, and free.
“This article was excerpted from the book Docker in Action
It is easy to get started building images if you are already familiar with using containers. A union file system (UFS) mount provides a container’s file system so any changes that you make to the file system inside a container will be written as new layers that are owned by the container that created them.
Before you work with real software, this article will detail the typical workflow using a Hello World example…”
http://www.developer.com/db/building-docker-images-from-a-container2.html
“One of the most useful features of any version control system is the ability to “undo” your mistakes. In Git, “undo” can mean many slightly different things.
When you make a new commit, Git stores a snapshot of your repository at that specific moment in time; later, you can use Git to go back to an earlier version of your project.
In this post, I’m going to take a look at some common scenarios where you might want to “undo” a change you’ve made and the best way to do it using Git…”
https://github.com/blog/2019-how-to-undo-almost-anything-with-git
“Git is currently the most widely used version control system in the world, mostly thanks to GitHub. By that measure, I’d argue that it’s also the most misunderstood version control system in the world.
This statement probably doesn’t ring true straight away because on the surface, Git is pretty simple. It’s really easy to pick up if you’ve come from another VCS like Subversion or Mercurial. It’s even relatively easy to pick up if you’ve never used a VCS before. Everybody understands adding, committing, pushing and pulling; but this is about as far as Git’s simplicity goes. Past this point, Git is shrouded by fear, uncertainty and doubt.
Once you start talking about branching, merging, rebasing, multiple remotes, remote-tracking branches, detached HEAD states… Git becomes less of an easily-understood tool and more of a feared deity. Anybody who talks about no-fast-forward merges is regarded with quiet superstition, and even veteran hackers would rather stay away from rebasing “just to be safe”…”
“Vaguely inspired by http://eagain.net/articles/git-for-computer-scientists, except this page is not just for CS folks. And it’s a lot more detailed. Oh, and it’s actively maintained, meaning I will respond to feedback ;-)…”
“This tutorial will show you how to set up a fully fledged Git server using SSH keys for authentication. It will not have a web interface, this will just cover getting Git installed and your access to it set up. We’ll use the host “git.droplet.com” in place of the domain you will use for your VPS…”
https://www.digitalocean.com/community/articles/how-to-set-up-a-private-git-server-on-a-vps
“Reverting a file can be a little confusing in git because git uses a different model than, say, SubVersion. You are in a catch-22 because to learn the model you need to know the terminology. To learn the terminology you need to know the model. I think the best explanations I’ve read so far have been in the book Pro Git, written by Scott Chacon and published by Apress. Scott put the entire book up online, and for that he deserves a medal. You can also buy a dead-tree version…”
thoughts... 