13 ms·

Flight rules for Git

203 points by spenrose 8y ago

lixtra 8y ago
I started version control with CVS. Just a bit better than copying. I started distributed version control with monotone. That felt better but the central db felt a bit unnatural. A bit later came mercurial and I was really happy with it. It all made sense. Easy interface and when you wanted to do something strange like rewrite history, you had to use a plugin. Then came git (rhymes to better know your sh*t). I'm not surrounded by the smartest guys but most people I met only have a superficial understanding of git and looking at these flight rules kind of confirms the complexity of git. I strongly believe that 80% of the current users of git would be better off with mercurial. But then everybody uses git for the remaining 20%.
- pavel_lishin 8y ago
  Mercurial doesn't have branches, right? That drove me bonkers when I was doing a bit of contract work after having used git for awhile. edit: They must have been using a different SCM; ignore me!
  - jfk13 8y ago
    https://www.mercurial-scm.org/wiki/Branch https://www.mercurial-scm.org/wiki/Branch Perhaps you're thinking of a different meaning of "branch"?
    - pavel_lishin 8y ago
      I must be thinking of a different SVN.
      - tome 8y ago
        You must be thinking of a different TLA.
        pavel_lishin 8y ago
        I am not having a good brain day today :P
  - deleted 8y ago
    [deleted]
  - BeetleB 8y ago
    They have had branches, at least since I started using hg (2010). But no one uses them. Everyone uses bookmarks as branches.
  - BerislavLopac 8y ago
    Not only that it has branches -- it has four different ways to branch. http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...
    - masklinn 8y ago
      Of note: Git has 3 of those: * git has clones * git has bookmarks, that's "normal" git branches * git has anonymous branches, it's called "detached head" and is completely broken * git does not have named branches (that's the branch name being part of the commit's immutable metadata)
      - dtech 8y ago
        > the branch name being part of the commit's immutable metadata To a git user, what's the rationale and when is this useful?
        lixtra 8y ago
        When you want to know were some commit came from. For example you can make a seemingly unrelated change in a feature branch. And then later wonder why this change has been done. Of course you could hope to find the merge into master where the feature name could be mentioned. But it’s nicer to have it on the commit. => it gives extra context to the commit
      - BerislavLopac 8y ago
        Well, considering one is broken I would still argue that it has two, just as the article states. Not that it needs much more -- git branching works perfectly fine. That said, I'm somewhat disappointed that cloning has fallen out of favour and it's standard to use an upstream server (usually GitHub) not only as a central authority but also as intermediary for sharing code. Apart from "forking", cloning repos has practically been delegated to history.
      - krupan 8y ago
        I've seen plenty of git users put "[JIRA-1234]" at the beginning of a string of commit messages. That's basically poor-man's mercurial named branches.
- BeetleB 8y ago
  >I strongly believe that 80% of the current users of git would be better off with mercurial. I concur. I was in a team that needed to migrate away from SVN. I was already privately using mercurial while in the team. Jumping to git was too much for them in complexity. I tried convincing them that mercurial will give them almost all the benefits without the (needless) complexity, but they wouldn't listen and ended up using TFS.
- XCabbage 8y ago
  Asking as someone who's never touched Mercurial: how is Mercurial simpler? Looking at https://confluence.atlassian.com/get-started-with-bitbucket/git-and-mercurial-commands-860009656.html https://confluence.atlassian.com/get-started-with-bitbucket/..., the conceptual model looks almost identical, and so do the commands for common tasks.
  - lixtra 8y ago
    git has 3+1 areas where a change can live: - working directory - staged - commited - (upstream) * hg has only 2+1 - working directory - commited - (upstream) * (*) both support something like stash but in hg it is easier to avoid that. git log shows you history depending on the checked out version hg log shows you the whole history of the branch, also after your checked out version. Knowing where you are is very valuable. in hg you can push multiple heads into a repo. that is very convenient when a junior is unable to merge something. to my understanding in git you need different branches. git - linus wants you to edit commits until they are perfect hg - mpm once said that you have to accpet mistakes that happen[1] as a consequence git has more advanced features very exposed while hg has a simple novice workflow [1] https://www.mercurial-scm.org/pipermail/mercurial/2006-June/008751.html https://www.mercurial-scm.org/pipermail/mercurial/2006-June/...
    - nemetroid 8y ago
      > (*) both support something like stash but in hg it is easier to avoid that. Incidentally, using shelve in hg is the only way I've ever lost work in a VCS (I've made the same error in git as well, but a dropped stash can be found again). > git log shows you history depending on the checked out version > hg log shows you the whole history of the branch, also after your checked out version. Knowing where you are is very valuable. git can show this, too, if you ask for it. If you've checked out some ancestor of `branch-name`, then `git log branch-name` will show `HEAD` next to the commit you've checked out. A single commit can belong to multiple branches, so if git showed you commits after your checked out version, which branch should it show? All of them? > git - linus wants you to edit commits until they are perfect You can use a never-rebase workflow in git as well, but most people elect not to.
okket 8y ago
FWIW here is a previous discussion from 4 years ago: https://news.ycombinator.com/item?id=8102624 https://news.ycombinator.com/item?id=8102624 (29 comments)
Narew 8y ago
that remember this so much https://xkcd.com/1597/ https://xkcd.com/1597/
wgerard 8y ago
A simpler guide, perhaps, made by an incredibly talented former co-worker of mine: https://ohshitgit.com/ https://ohshitgit.com/
- lprd 8y ago
  This looks great, thanks!
smacktoward 8y ago
It never ceases to amaze me that: 1. Git, a software product with more footguns per square inch of user-exposed surface than any I've ever encountered, ended up winning the distributed VCS sweepstakes; and 2. Even now, more than five years after it was clear to everyone that Git had won, there is absolutely no momentum to go back and clean it up to remove any of those footguns. All we get instead are increasingly shiny GUIs to hide them under, and well-meaning blog posts advising you on which is the best kind of tourniquet to apply when you trigger one of the aforementioned footguns. Sigh.
- feintruled 8y ago
  One consolation with Git, you know it is almost always possible to recover from any mistake. Theoretically anyway. I think we've all been in that situation where a team of engineers are huddling round a monitor strategizing about just how to undo the snafu of the day, brainstorming increasingly extreme solutions.
  - rtkwe 8y ago
    Every time I start to dig super deep on problems like this I stop for a second and wonder "just how important is it I fix this error" and "can this be solved by just paving over my local and reapplying my changes...". Most of the time the answer is not extremely and yes.
    - plorkyeran 8y ago
      It's true that for any given problem, learning how to fix it probably isn't worth the time. I've found the long-term benefits of taking the time to learn how to fix every problem I've run into (and importantly, understand what the things I'm doing to fix it do) to be very worth it, though. Over time I've had to google how to do fewer and fewer things, and when I do still need to google something it takes me much less time to understand the answer and how to apply it. As a polygot developer working in multiple languages, editors and ecosystems, git has been the one tool that I'm always using, and that makes it always worth investing more time into learning how to use it better.
Klathmon 8y ago
This only briefly touches on revert commits, and instead shows a lot of (in my opinion) dangerous history-destroying commands. Why aren't reverts more widely used? It seems a lot of devs I've worked with don't understand them, and to me they seem so simple and are so much safer than destroying/rewriting history.
- glormph 8y ago
  TIL there are revert commits, which prompted me to actually read the article and not just the HN comments. Thank you!
  - Klathmon 8y ago
    It's one of my favorite things in git! Don't "pretend the commit didn't happen", actually "undo" the commit (as in commit the reverse of your change). Not only does it preserve the change in an easy-to-see manner, but you can also provide more context on why you undid your commit (my revert messages often read like "Revert "previous commit message here" due to it potentially causing some older android devices to break. More info at ticket #1234") Now not only do you have a clear history of what happened (someone added X, then you undid X at a later date), but you also have context for why the change was undone, and can either revert the revert if you need to, or just re-do the work in a new commit later. It's a great "oh shit" button that I'm much more willing to use since I know I won't have to worry about "rescuing" the commit later. If something goes wrong and I have a hunch it was caused in a commit, i'll often just revert it and investigate later when I have time.
    - ascagnel_ 8y ago
      That, and since you're preserving commit history, you can later re-enable that change by making a second revert commit of the first revert.
- tome 8y ago
  They don't destroy history, they just move the branch to something that's not a descendant of what it once was. You can get the history back if you want. See "All the things your branch has ever been" http://h2.jaguarpaw.co.uk/posts/git-survival-guide/ http://h2.jaguarpaw.co.uk/posts/git-survival-guide/
dschuler 8y ago
This is interesting - I like looking at corner cases of a tool to understand it better. For people having difficulty with git, I recommend going through the official book [0] on a couple of topics with a toy repo and play with the tool a little bit. Another alternative is to find a simple workflow, and stick with it until you have time to explore git more. Compared to other tools I've had to use in the past (AccuRev ughh), git is fantastic. Just being able to see what files have been modified without waiting for 10min+ or needing to be connected to a server changes your workflow, but we've probably become accustomed to those benefits, but still notice the arguably crusty command line. [0] https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2
noxToken 8y ago
Everyone talks about how confusing Git is, and I think it's because they do'nt understand what the commands do. Don't get me wrong: you can royally screw up your repository with the wrong command, but 85% of your issues can be solved with checkout, pull, add, commit, push, merge, reset, status, stash, branch. When things get really heavy you may have to use rebase. And in spite of what people say, there is a nifty log that's perfect for revisiting a snapshot of your CLI's action: reflog. When I first started using Git, I was told, "When you want to make you commits public, use `git push -u origin <branch>` where branch the branch you're pushing to." That advice is technically correct, but I had no idea what -u nor origin was. I took 5 minutes to decipher the command. I walked away understand that origin an alias for the remote server, and that -u associates a remote branch with your local. I don't think Git is the greatest thing ever. I do think there's a bit of a learning curve. I also think that it's not as complicated as people make it seem. This post is a great reference for how to do X in Git, but it's a terrible source for beginners learning how to use Git. Cheat sheets are most effective when you have a basic understanding of the material.
- smacktoward 8y ago
  > Everyone talks about how confusing Git is, and I think it's because they do'nt understand what the commands do. If nobody understands what the commands do, the problem is with the commands, not with the people.
  - dtech 8y ago
    Git has a fair share of problems, but this command is not one of them. `git push -u origin <branch>` requires you to to understand tree things: push, remotes, and branches. Once you know what those are the command is straightforward. Those concepts are very fundamental to any DCVS. Maybe you can do the first steps in other DCVS's without this knowledge * , but doing everything but the trivial things will require you to understand these concepts. It's not strange that a tool solving a complicated problem for professional developers requires a bit of investment. * But so you can in git, learning this command by rote is a valid strategy for a new git user.
  - dasil003 8y ago
spenrose 8y ago
I also highly recommend Learn Git The Hard Way. Most developers who spend an afternoon with it will come away with a firm understanding of git's core abstractions. Book: https://leanpub.com/learngitthehardway https://leanpub.com/learngitthehardway
Sir_Cmpwn 8y ago
One of the reasons git is "hard" is because too many people read crap like this, which rapidly gets outdated and often contains more bad advice than good. Read the manual! It's not dry at all, and you'll learn a lot. Pick a random git command and read its man page right now. https://git-scm.com/docs https://git-scm.com/docs Read the git book, too. It's free and serves as a good introduction and helps you learn which man pages you need to consult and when. You don't need to read the whole thing, but the first 3 chapters are indispensible. https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2
- CleanShirt 8y ago
  Can you give some examples of how git has rapidly changed?
kureikain 8y ago
IMO, by blindly follow these kind of cheatsheet, you will hard to get better with Git. I used to remember command in certain situation and have a hard time understanding stuff like stash, rebase, cherry-pick, detach head etc...So whenever come up I have to sit google the heck out of it. Then one day I decide to sit down and just read Git properly. They are on: https://git-scm.com/ https://git-scm.com/ Eventually I understand it better and now I know what I need to do in certain situation.
marcosscriven 8y ago
Reminds me of the git man page generator joke site. https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/
jeffwass 8y ago
Seeking advice from the git masters : I joined a new small team several weeks ago. All of us are fairly new to git, coming from cvs and svn backgrounds. We use Intellij as our primary IDE, and bitbucket as our remote origin. Do y’all recommend using the IntelliJ git front end GUI, or calling git from the command line? I thought I had a grasp of git from some side projects on GitHub, but now that it’s a key dev tool in our daily process, the more I learn about it and need to extend beyond simple checkout/commit/push workflow, the deeper the rabbit hole goes.
- peheje 8y ago
  Learn the git cmd prompt first. Use a text editor eg. Code to fix merges. Git is powerful. And can have a hard learning curve, but don't have to. Learn it in CMD. I mostly use status push pull commit -a add checkout checkout -b branch list merge Gitk and git GUI usually comes with most installations and works for Mac Windows Linux. Then any other UI is just sugar.
- chopin 8y ago
  IntelliJ is missing tooling for staging which I am missing. Imho the Eclipse tooling (EGit) is much better in that regard. I never had trouble mixing Eclipse and command line workflows whereas IntelliJ forces me more often to resort to the command line. As the sibling said, learning the command line first (and the model of Git) is mandatory, especially if you come from a CVS and SVN background. I came from Perforce and had a pretty hard time with Git until I invested two days with a good tutorial and much experimenting with two local and one remote repository. EDIT: spelling
projectramo 8y ago
Isn't the first rule, never talk about Flight rules?
anonuser123456 8y ago
If git confuses Read chapter 10 of pro git Mourn enlightenment
pvinis 8y ago
Any suggestions for quickly doing the following: When I clone a former repo on GitHub, I want to also add the original repo I formed from, as the upstream remote. This way I have the original repo which is mine and the upstream repo which is the original. So far I've been doing this manually.
- SpaceNugget 8y ago
  go to https://github.com/github/hub https://github.com/github/hub install hub and run: hub fork user/repo
xtracto 8y ago
I was surprised there is no mention of git bisect... an incredibly useful tool.

203 points by spenrose 8y ago

I started version control with CVS. Just a bit better than copying. I started distributed version control with monotone. That felt better but the central db felt a bit unnatural. A bit later came mercurial and I was really happy with it. It all made sense. Easy interface and when you wanted to do something strange like rewrite history, you had to use a plugin. Then came git (rhymes to better know your sh*t). I'm not surrounded by the smartest guys but most people I met only have a superficial understanding of git and looking at these flight rules kind of confirms the complexity of git. I strongly believe that 80% of the current users of git would be better off with mercurial. But then everybody uses git for the remaining 20%.

pavel_lishin 8y ago
Mercurial doesn't have branches, right? That drove me bonkers when I was doing a bit of contract work after having used git for awhile. edit: They must have been using a different SCM; ignore me!
- jfk13 8y ago
  https://www.mercurial-scm.org/wiki/Branch https://www.mercurial-scm.org/wiki/Branch Perhaps you're thinking of a different meaning of "branch"?
  - pavel_lishin 8y ago
    I must be thinking of a different SVN.
    - tome 8y ago
      You must be thinking of a different TLA.
      - pavel_lishin 8y ago
        I am not having a good brain day today :P
- deleted 8y ago
  [deleted]
- BeetleB 8y ago
  They have had branches, at least since I started using hg (2010). But no one uses them. Everyone uses bookmarks as branches.
- BerislavLopac 8y ago
  Not only that it has branches -- it has four different ways to branch. http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...
  - masklinn 8y ago
    Of note: Git has 3 of those: * git has clones * git has bookmarks, that's "normal" git branches * git has anonymous branches, it's called "detached head" and is completely broken * git does not have named branches (that's the branch name being part of the commit's immutable metadata)
    - dtech 8y ago
      > the branch name being part of the commit's immutable metadata To a git user, what's the rationale and when is this useful?
      - lixtra 8y ago
        When you want to know were some commit came from. For example you can make a seemingly unrelated change in a feature branch. And then later wonder why this change has been done. Of course you could hope to find the merge into master where the feature name could be mentioned. But it’s nicer to have it on the commit. => it gives extra context to the commit
    - BerislavLopac 8y ago
      Well, considering one is broken I would still argue that it has two, just as the article states. Not that it needs much more -- git branching works perfectly fine. That said, I'm somewhat disappointed that cloning has fallen out of favour and it's standard to use an upstream server (usually GitHub) not only as a central authority but also as intermediary for sharing code. Apart from "forking", cloning repos has practically been delegated to history.
    - krupan 8y ago
      I've seen plenty of git users put "[JIRA-1234]" at the beginning of a string of commit messages. That's basically poor-man's mercurial named branches.
BeetleB 8y ago
>I strongly believe that 80% of the current users of git would be better off with mercurial. I concur. I was in a team that needed to migrate away from SVN. I was already privately using mercurial while in the team. Jumping to git was too much for them in complexity. I tried convincing them that mercurial will give them almost all the benefits without the (needless) complexity, but they wouldn't listen and ended up using TFS.
XCabbage 8y ago
Asking as someone who's never touched Mercurial: how is Mercurial simpler? Looking at https://confluence.atlassian.com/get-started-with-bitbucket/git-and-mercurial-commands-860009656.html https://confluence.atlassian.com/get-started-with-bitbucket/..., the conceptual model looks almost identical, and so do the commands for common tasks.
- lixtra 8y ago
  git has 3+1 areas where a change can live: - working directory - staged - commited - (upstream) * hg has only 2+1 - working directory - commited - (upstream) * (*) both support something like stash but in hg it is easier to avoid that. git log shows you history depending on the checked out version hg log shows you the whole history of the branch, also after your checked out version. Knowing where you are is very valuable. in hg you can push multiple heads into a repo. that is very convenient when a junior is unable to merge something. to my understanding in git you need different branches. git - linus wants you to edit commits until they are perfect hg - mpm once said that you have to accpet mistakes that happen[1] as a consequence git has more advanced features very exposed while hg has a simple novice workflow [1] https://www.mercurial-scm.org/pipermail/mercurial/2006-June/008751.html https://www.mercurial-scm.org/pipermail/mercurial/2006-June/...
  - nemetroid 8y ago
    > (*) both support something like stash but in hg it is easier to avoid that. Incidentally, using shelve in hg is the only way I've ever lost work in a VCS (I've made the same error in git as well, but a dropped stash can be found again). > git log shows you history depending on the checked out version > hg log shows you the whole history of the branch, also after your checked out version. Knowing where you are is very valuable. git can show this, too, if you ask for it. If you've checked out some ancestor of `branch-name`, then `git log branch-name` will show `HEAD` next to the commit you've checked out. A single commit can belong to multiple branches, so if git showed you commits after your checked out version, which branch should it show? All of them? > git - linus wants you to edit commits until they are perfect You can use a never-rebase workflow in git as well, but most people elect not to.

okket 8y ago

FWIW here is a previous discussion from 4 years ago: https://news.ycombinator.com/item?id=8102624 https://news.ycombinator.com/item?id=8102624 (29 comments)

Narew 8y ago

that remember this so much https://xkcd.com/1597/ https://xkcd.com/1597/

wgerard 8y ago

A simpler guide, perhaps, made by an incredibly talented former co-worker of mine: https://ohshitgit.com/ https://ohshitgit.com/

lprd 8y ago
This looks great, thanks!

smacktoward 8y ago

It never ceases to amaze me that: 1. Git, a software product with more footguns per square inch of user-exposed surface than any I've ever encountered, ended up winning the distributed VCS sweepstakes; and 2. Even now, more than five years after it was clear to everyone that Git had won, there is absolutely no momentum to go back and clean it up to remove any of those footguns. All we get instead are increasingly shiny GUIs to hide them under, and well-meaning blog posts advising you on which is the best kind of tourniquet to apply when you trigger one of the aforementioned footguns. Sigh.

feintruled 8y ago
One consolation with Git, you know it is almost always possible to recover from any mistake. Theoretically anyway. I think we've all been in that situation where a team of engineers are huddling round a monitor strategizing about just how to undo the snafu of the day, brainstorming increasingly extreme solutions.
- rtkwe 8y ago
  Every time I start to dig super deep on problems like this I stop for a second and wonder "just how important is it I fix this error" and "can this be solved by just paving over my local and reapplying my changes...". Most of the time the answer is not extremely and yes.
  - plorkyeran 8y ago
    It's true that for any given problem, learning how to fix it probably isn't worth the time. I've found the long-term benefits of taking the time to learn how to fix every problem I've run into (and importantly, understand what the things I'm doing to fix it do) to be very worth it, though. Over time I've had to google how to do fewer and fewer things, and when I do still need to google something it takes me much less time to understand the answer and how to apply it. As a polygot developer working in multiple languages, editors and ecosystems, git has been the one tool that I'm always using, and that makes it always worth investing more time into learning how to use it better.

Klathmon 8y ago

This only briefly touches on revert commits, and instead shows a lot of (in my opinion) dangerous history-destroying commands. Why aren't reverts more widely used? It seems a lot of devs I've worked with don't understand them, and to me they seem so simple and are so much safer than destroying/rewriting history.

glormph 8y ago
TIL there are revert commits, which prompted me to actually read the article and not just the HN comments. Thank you!
- Klathmon 8y ago
  It's one of my favorite things in git! Don't "pretend the commit didn't happen", actually "undo" the commit (as in commit the reverse of your change). Not only does it preserve the change in an easy-to-see manner, but you can also provide more context on why you undid your commit (my revert messages often read like "Revert "previous commit message here" due to it potentially causing some older android devices to break. More info at ticket #1234") Now not only do you have a clear history of what happened (someone added X, then you undid X at a later date), but you also have context for why the change was undone, and can either revert the revert if you need to, or just re-do the work in a new commit later. It's a great "oh shit" button that I'm much more willing to use since I know I won't have to worry about "rescuing" the commit later. If something goes wrong and I have a hunch it was caused in a commit, i'll often just revert it and investigate later when I have time.
  - ascagnel_ 8y ago
    That, and since you're preserving commit history, you can later re-enable that change by making a second revert commit of the first revert.
tome 8y ago
They don't destroy history, they just move the branch to something that's not a descendant of what it once was. You can get the history back if you want. See "All the things your branch has ever been" http://h2.jaguarpaw.co.uk/posts/git-survival-guide/ http://h2.jaguarpaw.co.uk/posts/git-survival-guide/

dschuler 8y ago

This is interesting - I like looking at corner cases of a tool to understand it better. For people having difficulty with git, I recommend going through the official book [0] on a couple of topics with a toy repo and play with the tool a little bit. Another alternative is to find a simple workflow, and stick with it until you have time to explore git more. Compared to other tools I've had to use in the past (AccuRev ughh), git is fantastic. Just being able to see what files have been modified without waiting for 10min+ or needing to be connected to a server changes your workflow, but we've probably become accustomed to those benefits, but still notice the arguably crusty command line. [0] https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2

noxToken 8y ago

Everyone talks about how confusing Git is, and I think it's because they do'nt understand what the commands do. Don't get me wrong: you can royally screw up your repository with the wrong command, but 85% of your issues can be solved with checkout, pull, add, commit, push, merge, reset, status, stash, branch. When things get really heavy you may have to use rebase. And in spite of what people say, there is a nifty log that's perfect for revisiting a snapshot of your CLI's action: reflog. When I first started using Git, I was told, "When you want to make you commits public, use `git push -u origin <branch>` where branch the branch you're pushing to." That advice is technically correct, but I had no idea what -u nor origin was. I took 5 minutes to decipher the command. I walked away understand that origin an alias for the remote server, and that -u associates a remote branch with your local. I don't think Git is the greatest thing ever. I do think there's a bit of a learning curve. I also think that it's not as complicated as people make it seem. This post is a great reference for how to do X in Git, but it's a terrible source for beginners learning how to use Git. Cheat sheets are most effective when you have a basic understanding of the material.

smacktoward 8y ago
> Everyone talks about how confusing Git is, and I think it's because they do'nt understand what the commands do. If nobody understands what the commands do, the problem is with the commands, not with the people.
- dtech 8y ago
  Git has a fair share of problems, but this command is not one of them. `git push -u origin <branch>` requires you to to understand tree things: push, remotes, and branches. Once you know what those are the command is straightforward. Those concepts are very fundamental to any DCVS. Maybe you can do the first steps in other DCVS's without this knowledge * , but doing everything but the trivial things will require you to understand these concepts. It's not strange that a tool solving a complicated problem for professional developers requires a bit of investment. * But so you can in git, learning this command by rote is a valid strategy for a new git user.
- dasil003 8y ago

spenrose 8y ago

I also highly recommend Learn Git The Hard Way. Most developers who spend an afternoon with it will come away with a firm understanding of git's core abstractions. Book: https://leanpub.com/learngitthehardway https://leanpub.com/learngitthehardway

Sir_Cmpwn 8y ago

One of the reasons git is "hard" is because too many people read crap like this, which rapidly gets outdated and often contains more bad advice than good. Read the manual! It's not dry at all, and you'll learn a lot. Pick a random git command and read its man page right now. https://git-scm.com/docs https://git-scm.com/docs Read the git book, too. It's free and serves as a good introduction and helps you learn which man pages you need to consult and when. You don't need to read the whole thing, but the first 3 chapters are indispensible. https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2

CleanShirt 8y ago
Can you give some examples of how git has rapidly changed?

kureikain 8y ago

IMO, by blindly follow these kind of cheatsheet, you will hard to get better with Git. I used to remember command in certain situation and have a hard time understanding stuff like stash, rebase, cherry-pick, detach head etc...So whenever come up I have to sit google the heck out of it. Then one day I decide to sit down and just read Git properly. They are on: https://git-scm.com/ https://git-scm.com/ Eventually I understand it better and now I know what I need to do in certain situation.

marcosscriven 8y ago

Reminds me of the git man page generator joke site. https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/

jeffwass 8y ago

Seeking advice from the git masters : I joined a new small team several weeks ago. All of us are fairly new to git, coming from cvs and svn backgrounds. We use Intellij as our primary IDE, and bitbucket as our remote origin. Do y’all recommend using the IntelliJ git front end GUI, or calling git from the command line? I thought I had a grasp of git from some side projects on GitHub, but now that it’s a key dev tool in our daily process, the more I learn about it and need to extend beyond simple checkout/commit/push workflow, the deeper the rabbit hole goes.

peheje 8y ago
Learn the git cmd prompt first. Use a text editor eg. Code to fix merges. Git is powerful. And can have a hard learning curve, but don't have to. Learn it in CMD. I mostly use status push pull commit -a add checkout checkout -b branch list merge Gitk and git GUI usually comes with most installations and works for Mac Windows Linux. Then any other UI is just sugar.
chopin 8y ago
IntelliJ is missing tooling for staging which I am missing. Imho the Eclipse tooling (EGit) is much better in that regard. I never had trouble mixing Eclipse and command line workflows whereas IntelliJ forces me more often to resort to the command line. As the sibling said, learning the command line first (and the model of Git) is mandatory, especially if you come from a CVS and SVN background. I came from Perforce and had a pretty hard time with Git until I invested two days with a good tutorial and much experimenting with two local and one remote repository. EDIT: spelling

projectramo 8y ago

Isn't the first rule, never talk about Flight rules?

anonuser123456 8y ago

If git confuses Read chapter 10 of pro git Mourn enlightenment

pvinis 8y ago

Any suggestions for quickly doing the following: When I clone a former repo on GitHub, I want to also add the original repo I formed from, as the upstream remote. This way I have the original repo which is mine and the upstream repo which is the original. So far I've been doing this manually.

SpaceNugget 8y ago
go to https://github.com/github/hub https://github.com/github/hub install hub and run: hub fork user/repo

xtracto 8y ago

I was surprised there is no mention of git bisect... an incredibly useful tool.