Guess what happens if you try to git revert a merge? Yeah. Don’t do that.
You can, but you really need to understand what happens when you do so, so that you're not confused by future merges from the same branch. Straight from the horse's mouth:
Like if you created a new branch from master and you have been merging master into your branch to get updates in master, once you merge your branch into master you cannot revert this merge because the act of merging master into your branch changed which branch owned commits.
If you rebased master into your branch instead everything will be fine. If you merge your branch into master, reverting that merge will simply undo the merge as you expected.
Being able to pick and choose (and even edit) individual chunks to be staged is enormously useful. Quite possibly my favourite feature of git.
For instance, in git add -i, the command to stage changes is called "update". The command to unstage is called "revert". Further, does _anybody_ use interactive adding when not intending to stage individual hunks from some file ? Yet there are all these other commands in there to stage/unstage whole files, which are more easily and uniformly done from the command line tools (well, when you accept that staging is called "add"ding on the command line and unstaging is called "reset"ting).
If you ever want that functionality on a non-git VCS, I co-wrote a tool that does just that (it predates git, actually) called commit-patch. It integrates into Emacs nicely and also has 'commit-partial' for a nice command-line interface.
Mine, too. Fortunately, mercurial has that feature, too. (Though you might need a plugin.)
Lots and lots of rebase -i.
However, git lets you fix the mess in such a way that you'll have a clean commit history. This is really helpful if you're trying to keep your codebase clean so that `git bisect` will always work nicely, and if you just want to keep your codebase history really grokkable.
When I do personal development or small side projects I could care less about my history being clean. Nothing is ever so large or complex that it needs to be fixed in such a meticulous manner. It may feel that way, until you start working on larger software. The stress of a $1,000-$20,000 job is laughable compared to the scale of enterprise failure.
In enterprise, it's often the case that applications are built by teams of people in constant flux. They may need to be patched or rolled back at a moment's notice, and every hour the bug stays live is an hour of enormous financial burden to the client and intense stress on my employer. In this case, having a trustworthy VCS with a clean history in invaluable.
I hope of course that people realize you should not rely on this as an educational tool but merely as a quick reference. Please, don't use any of these commands without knowing what they do!
Let's say you are working on a feature branch and you accidentally commit it to the upstream branch before you're ready. Intuitively, you might then revert the merge changeset, continue working on your feature branch for a while, and then when you're done, merge it back upstream.
That would be wrong.
What will actually happen is that when you do the second merge, only the changes you made after the reverted merge will be applied to the upstream branch. All the work that was "reverted" in the initial mistaken merge will be missing, even after the second merge! This can be very confusing, since there's no indication to the developer where it went. It's just gone.
The fix at that point it to revert the revert changeset. But the real solution is to never revert a merge.
Would you like to know more? http://knowyourmeme.com/memes/you-keep-using-that-word-i-do-...
I think there is a small mistake though, for the "I accidentally commited something": the answers yes and no for "Has anyone else seen it?" are inverted.
The answers for "no" all involve modifying history, which I think is generally perceived to be quite OK so long as you aren't modifying history that is public.
This is an area where I get completely lost with regard to the 'right' thing to do to fix things up.
sadly, my company decided to move just to use pull requests as a poor man's code review tool. sigh. I'm the 99%
1. Not having to check out files means I can work offline.
2. When working on multiple features, it's much easier to create a new Git branch than it is to create a new Perforce workspace.
3. People really tend to abuse Perforce's 'lock file' feature. I'm glad this isn't possible in Git.
4. I haven't really noticed any drawbacks to the pull-request feature. You can still review and comment on diffs on Github.
5. It's the version control of choice for open source software, so if you use any third-party libraries (and I hope you do!), you'll probably need to know how to use Git anyway.
I can't really think of anything I miss from Perforce.
Edit: these advantages are not specific to Git, but any distributed version control system. If you find Git to be too difficult, don't worry, it's not the only game in town. I've heard Mercury is much easier to pick up. Good luck!
i known it's the open source favorite. because it solve that problem.
for me all my corporate projects where in hg before git became a fad. but i guess I'm afraid of change/can't read a manual.
Only when you don't give any substantive reasons and just talk about how difficult it is. It just seems difficult because it's a different way of thinking.
>>i known it's the open source favorite. because it solve that problem.
So you do agree that it solves a real problem, it isn't just a fad. Also, a lot of companies like to attract good talent by open sourcing some of their internal libraries. Since they'll be using git for that anyway, makes sense to use git as their main VCS.
>>but i guess I'm afraid of change/can't read a manual.
You're taking this way too personally. I'm just saying give it a fair shot and come up with objective problems with it. No one will take you seriously with "I don't like it because it's too hard". You're better than that.
Also "using" a third-party library hopefully results in finding bugs, fixing them, and submitting a pull request to the project.
When did using git-based package managers become the norm?
> it wasn't uncommon to track/update dependencies manually using command-line git.
Are you saying you normally update your third-party libs with the latest from HEAD instead of using versioned release artifacts?
(I'm guessing you're speaking from a JS dev perspective?)
I'm a web developer, so my response was hastily written thinking about my own narrow scope. I'm sure that non-web developers can go their whole lives without interacting with git, but it's impossible for web developers.
Npm (Node), Composer (PHP), and Bower (web) package managers all use git (and often GitHub itself) pretty religiously. I know that one or more of those may support other VCS repos, but git is the de facto flavor.
> Are you saying you normally update your third-party libs with the latest from HEAD instead of using versioned release artifacts?
Not exactly. First of all, that's what I _used_ to do before every language had its own package manager.
Second, I do use versioned releases. However, I use the tagged versions that are determined by the author(s) of the library. I'm not just pulling down a bleeding-edge, un-tested library, and I don't get every single commit.
1. Nuget packages inside Visual Studio
2. Download the library using a web browser, and just put it where it needs to be.
I'm sure some people would scoff at this list, but it does demonstrate that you can certainly use third party libraries without using git.
That might work for certain projects, but let's say you're using 10 third-party libraries. If they're under active development, you can expect at least a few security updates between the time you first import them and the time you ship your own product.
It's not very practical (especially for a programmer!) to keep manually checking your dependencies' product pages for updates.
I recently switched a project from Darcs to git. It was (again) mostly centrally contained, despite being a DVCS. And Darcs being DVCS, we held out on switching to Git since it seemed like it wouldn't really be that much of an improvement. In other words, change for change sake.
Boy was I wrong. Even that change was refreshing. I find Git to be an absolute pleasure to use (and as a plus it stole all the good Darcs interface features). Git made managing our release branch fun again. The thing I like about Git is that it's low level enough that you can make it do anything.
Like the time I foolishly changed the EOLs on upstream code after I committed it—Git let me track my changes and merge in new upstreams, despite every line in the new upstream being different. Yay, git.
The first thing we did after converting the Darcs repo to Git was to run a complicated rebase script that split all the dev repo patches into logical git branches. If you looked at the Git repo at that point it would be a single linear set of commits which then explodes into 14 or 15 different branches all at the same point.
Since then we've been using feature branches to do our development and Git really helps to keep distractions to a minimum. "git stash" and feature branches mean that random stuff I am trying is filed away neatly and doesn't pollute my working directory like it did when we were Darcs based.
Honestly I don't really miss anything from Darcs. I could fib and say Darcs's cherry-picking is better than Git's, but while that's true, I don't really cherry pick much in Git (it's usually only to fix accidental checkins on the wrong branch) and so I don't hit conflicts often (at all, really).
Darcs allowed us really simple deployment (we'd just push our patches to the live server—not the cleanest, but oh so easy). Git required us to write a hook that deploys when we push to the production branch. However, that was actually a blessing in disguise, since now the hook can do good stuff like reload the server when the code changes and rebuild static assets as appropriate. We used to just do that by hand.
It is so simple to create a new git repo on the fly, with no need for a separate repository location. And rebasing plus easy branching has changed the way I work forever. Git allows you to commit early and commit often, safe in the knowledge you can always reorder, combine, remove and/or re-comment your changes later.
This frees you to experiment without worrying about losing the progress you've already made. If you reach a dead-end, it's easy to go back and start working in another direction, while saving the branch in case you change your mind.
Basically, once you get past the learning curve, git makes it extremely easy to remain in that most blessed of version control state of having no uncommitted local changes. And once you've saved with with a commit, it's pretty hard to permanently lose it.
at least, before you push changes to another repo, if you're doing that.
Using Git, and using pull requests as code reviews are two very separates things. Many people addressed the first point (e.g. Why git is totally fine), so I'll focus on the second one: code reviews with Git. Pull requests is one of many ways to do it, which I personally find difficult with bigger teams working on non open-source projects. I'd recommend looking at Phabricator as a code review tool that works really well in teams.