Am 9/23/2011 6:48, schrieb Jon Forrest: > I'm just now starting to use git for more than trivial things. > Today I got myself in trouble. Here's what happened: > > 1) I pulled the master branch from the IT repository from our > main git server. > > 2) I created a branch from this called "J" and started making changes. > > 3) Other people pulled master from IT and then pushed changes back. OK, so you are basically using a central repo. > 4) I merged J with my master branch. > > 5) I tried pushing my master back to origin but this failed with > the usual message saying I first needed to pull from origin. > So, I pulled and then pushed. This worked. > > 6) On another server where I was going to use my changes I pulled > master from IT. I assume you mention this because with this step you detected that your changes were crap. > 6) It turned out that my changes were incorrect. So, I tried to revert > using various methods I found by googling "git revert". What happened > was that when I tried to revert back to the commit before the one I > made, the files I had modified *and* the files that apparently were > modified by other people in #3 above were reverted. This wasn't what > I wanted. I only wanted to revert the changes I had made. It looks like you had reset the history, not just reverted your changes. > With the help of someone more experienced than me we were able to get > things back to normal but this experience left me wondering what I > should have done in the first place. There's a chance I'm going to > have to go through all this again as I try to fix the problem with > my changes. With a central repository, any push into it marks a "done deal". No matter how wrong and bogus your changes are, as soon as you push them into the central repository, they are cast in stone. At this point, the best you can do is to revert you changes, and by this I mean that you create and push out another commit on top that backs out the changes that you made. If this is not what you (or your team) wants, than the problem is not with suboptimal use of the git toolset, but with the push policy within you team. A good policy should forbid that untested stuff can be pushed into the central repository. My suggestion is that you find a way to move your changes to the test site (the "another server" you mention in step 6) without going through the central repository. For example, if you have ssh access between your development machine and the test site, you can push or pull your changes between them directly. -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html