8 ms·
Git pretty
- chetanahuja 12y agomagit mode in emacs has bailed me out numerous times from git messes. If you're an emacs and git user but not using magit, you're seriously missing out.
- npsimons 12y agoDunno, I've been very happy with egg. But then, due to a large part of my career being maintenance, I've fallen into a lot of self-discipline patterns that tend to keep me out of messes.
- rcthompson 12y agoegg looks pretty similar to magit in terms of functionality. I haven't tried it, but I would guess either one is fine.
- scrollaway 12y agoThat is a really fun poster to have! 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!
- aristidb 12y agoThere should be a section for git filter-branch. :>
- js2 12y agoThis is excellent: opinionated and correct. 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: https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt https://www.kernel.org/pub/software/scm/git/docs/howto/rever...
- bellerocky 12y agoReverting a merge is totally OK if you kept your history clean and rebased the branch you're merging into to get updates instead of merging it into your branch. 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.
- deleted 12y ago[deleted]
- michaelmior 12y agoWhile I agree this guide is great, I think opinionated and correct are mutually exclusive.
- chrisweekly 12y ago"...opinionated and correct are mutually exclusive." TIMTOWTDI.
- michaelmior 12y agoVery true, but whenever that is the case, there are typically some who decide their way is the "right" way for various reasons.
- pjungwir 12y agoI've read that doc and other warnings about reverting a merge. But I've found that if you revert the revert, then you avoid the problems they mention. I guess the worry is that you still have to remember to do that, or you'll have commits that silently never merge. But if you do remember, then reverting the revert makes things okay. But I'm no expert. Can anyone else confirm this for me?
- philip1209 12y agoIf you really mess things up, there is Reflog
- ladislas 12y agoGreat tool for young interns! :D 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.
- burntsushi 12y agoHmm, I don't think so. The answer for "yes" is to do a `git revert`, which does not modify history. Instead, it creates a new commit. 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.
- ladislas 12y agoyep you're right and the question was already answered in the comments. :)
- jrochkind1 12y agoSO useful, thanks! This is an area where I get completely lost with regard to the 'right' thing to do to fix things up.
- tarblog 12y agoWhat does "I don't think it means what you think it means" refer to?
- christop 12y agoPossibly that `git revert` doesn't somehow remove the commit you've done, rather it creates a new commit removing the changes, along with a commit message saying which commit is being reverted.
- bkeroack 12y agoReverting a merge commit is the big danger zone. 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.
- J_Darnley 12y agoAs well as what my sibling comments said, it is also a reference to The Princess Bride. Would you like to know more? http://knowyourmeme.com/memes/you-keep-using-that-word-i-do-not-think-it-means-what-you-think-it-means http://knowyourmeme.com/memes/you-keep-using-that-word-i-do-...
- pimlottc 12y agoI don't think it's specifically about reverting merge commits but rather the fact that "git revert" is quite different from "svn revert" which may not be immediately clear and may not meet everyone's understanding of the term "revert" - which is to say, it does not simply "get rid of" the unwanted commit but rather creates a new one that has the net effect of undoing that commit's changes.
- christop 12y ago"Split off a logical chunk from your mess, stage it" should really be another box with "git add -p". Being able to pick and choose (and even edit) individual chunks to be staged is enormously useful. Quite possibly my favourite feature of git.
- bobthecow 12y agoThat's in the tl;dr
- adregan 12y agogit add -p has absolutely changed my work flow and commit histories for the better.
- adestefan 12y agoI find that git add -p is a crutch and everytime I need to use it I scold myself for not committing more often.
- serge2k 12y agoThat does sound useful, I have a bad habit of letting things get messy. Lots and lots of rebase -i.
- digikata 12y agoI agree with the git add -p , but I feel that at point, it often should be followed by a stash then a rebuild and/or some testing. Next, commit and unstash to continue.
- bobthecow 12y agoYep yep. `git add -p`, `git stash -p`, etc. That's exactly why that bit of the chart isn't very specific. There's a whole workflow right there, in that one little cycle. One of these days I'll get around to writing that one up :)
- 12y ago
- JoshTriplett 12y agoNice chart, at least for a reminder of the command you're likely to need. However, "Is it already on GitHub" should be "have you already pushed it publically". Reminder: git is distributed.
- rwallace 12y agoGit is distributed indeed, but good writing style prefers specifics to abstract generalities. It's better to use Github as your example and expect the reader to understand - or if appropriate, explain in a separate paragraph - that there are other options for public repositories.
- gcb4 12y agogit is only good for people that was working like Linus. if you didn't have been accepting patches by email but instead had a fluid svn, perforce, etc central repository and people already collaborating with commit powers, then if you move to git "just because" (which is the reason of 99% migrations) you're going to have a bad time. sadly, my company decided to move just to use pull requests as a poor man's code review tool. sigh. I'm the 99%
- findjashua 12y agoSounds more like resistance to change than anything wrong with Git. I used perforce at my previous company, and while Git's learning curve was higher, I definitely see the advantages of a distributed version control system over a centralized one: 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!
- recursive 12y agoWhy would you need to know how to use any version control software at all to use a third party library? I mean, I do both, but haven't really seen a connection.
- smt88 12y agoBefore git-based package managers became the norm, it wasn't uncommon to track/update dependencies manually using command-line git. Also "using" a third-party library hopefully results in finding bugs, fixing them, and submitting a pull request to the project.
- fiatjaf 12y ago"Do you hate them?" was hilarious.
- nathancahill 12y agoIf you like this, check out gitjk[0], it's saved my codebase a handful of times. [0] https://github.com/mapmeld/gitjk https://github.com/mapmeld/gitjk
- LandonAB 12y agoAs a one person web design/development studio, it's charts like this and threads like this that keep me off git. I've played with it, used it on a project but the fact that I am always reading about the messes people get in with git...I really don't have time to deal with versioning messes.
- chunkstuntman 12y agoI think any version control software needs to address the simple fact that humans will rush through writing and committing code in a way that they may later regret. Dealing with an ugly git log is less trouble than not having versioning software at all.
- LandonAB 12y agoYes, you are correct. I'm just not facing the inevitable apparently.
- apinstein 12y agoI'd counter that these messes aren't caused by git; rather they are messes that without git you wouldn't even bother cleaning up. 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.
- LandonAB 12y agoOh, I'm not blaming git. I take full blame but still have a hard time rationalizing the headache.
- tericho 12y agoI do both enterprise and one person dev studio work and use Git for both. 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.
- krallja 12y agoMercurial Changeset Evolution is going to solve the "It's safest to let it stay ugly then" and "Send them a note, let 'em know you're changing history" problems. No more force pushes or lost data! The new version of history applies on top of the old version. Immutable data structures, flexible workflow.