8 ms·

Honestly I still find a lot of engineers don't know git properly. Like they know enough to commit and push but that's about it. It really helps to understand ev

by augbog 7y ago

Honestly I still find a lot of engineers don't know git properly. Like they know enough to commit and push but that's about it. It really helps to understand everything git has to offer.

333c 7y ago
The three most important basic git operations to know (in my opinion) git checkout -b git log git rebase -i
- jimpudar 7y ago
  I also find git blame extremely useful, along with code exploration tools like DeepGit [0] [0] https://www.syntevo.com/deepgit/ https://www.syntevo.com/deepgit/
- dwoot 7y ago
  I'll have to add `git reflog` for instances where you've felt that you've completely screwed up something as one can always move back to a previous state. I think this is essential. A useful one that I'll add is what I call the sword command: `git log -S<word>` This one allows one to list commits that contain a particular change. This has been useful in tracking down old changes
- btilly 7y ago
  I strongly prefer git merge over git rebase. Using rebase results in a cleaner history and simplified workflow in many cases. However it also means that when you have a disaster, it can be truly unrecoverable. I hope you have an old backup because you told your source control system to scramble its history, and you don't have any good way to back it out later. For those who don't know what I mean, the funny commit ids that git produces are a hash signifying the current state of the repository AND the complete history of how you got there. Every time you rebase you take the other repository, and its history, and then replay your new commits as happening now, one after the other. Now suppose that you rebased off of a repository. Then the repository is rebased by someone else. Now there is no way to merge your code back except to --force it. And that means that if your codebase is messed up, you're now screwed up with history screwed up and no good way to sort it out. That result is impossible if you're using a merge based result. The cost is, though, that the history is accurately complicated. And the existence of a complex history is a huge problem for useful tools like git bisect.
  - 333c 7y ago
    I work on a small open source project. Our master branch is protected from force pushes, and I only use rebase on personal branches for features or bug fixes. It's very nice if I'm planning to merge several commits but I need to fix something in one or more of them. I agree that rebasing should not happen in the main branch(es) of a repo.
  - jonahx 7y ago
    Linus on rebase: https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html https://www.mail-archive.com/dri-devel@lists.sourceforge.net...
  - james_s_tayler 7y ago
    I don't know. Since git uses content-based addressing, you can't actually alter any commit, only create new ones. And orphaned commits don't get garbage collected for like 30 days even if you explicitly tell git to clean things up. So, the original stuff will still be there. It might just not be obvious how to access it. Part of the commit is the reference to zero or more parent commit object ids. So, if you find the old commit, it still has it's history intact. `git log -g` is a handy command to see a composite git log that travels across branch changes. I do get what you mean though. You effectively create new commits with an alternate view of history. I don't get quite why/how that causes a situation in which the code can't be merged? I don't rebase much, I prefer merging. Is there any resource that can explain why rebasing might be dangerous like that? In general if branches diverge too far then you have difficulties merging no matter which strategy you use and sometimes if it diverges too far it just becomes hopeless. Mostly though if you are working in a team, commit daily and merging/rebasing frequently it should present fairly few problems. I find I never run the actual command git bisect. I just do `git log --decorate --oneline --graph` and eyeball a good commit to start from and then basically do it by hand using commit messages to aid in making reasonable guesses as to where to try but following the basic binary search philosophy. Works well enough even with a complex history.
    - btilly 7y ago
      Here is an example of how to create a problem. You rebase your private branch off of a shared master and pull in other people's commits. Someone else pushes out their rebased version using force. More commits are made on top of the other people's commits, including reversing some bad commits. You try to rebase off of the shared master. In your last rebase, you are trying to replay all of the commits in your history that are not in the remote history. However git does not understand which local commits are from you and not pulled in on the previous rebase. It therefore tries to play them on top of the remote master if it can make sense of them. Which means that you bring back the reversed commits. You might find conflicts in code that you have not touched. You resolve them as best you may. And now you've got the definitive version of what happens, and no way with the screwed up history to figure out why it is going to go wrong. Then you force commit because that is how a rebase flow works..and everyone is screwed. I agree on branches diverging too far. Merge early, merge often. If you never run the command to git bisect, you should try it. What it's for is finding the random commit that recently broke a piece of functionality that nobody realized would break. Because nobody realized it, the log messages will say nothing useful. And you don't need to figure out where the change is - just write a test program for the breakage, run git bisect, and look at the offending commit.
- bshacklett 7y ago
  `git add -p` changed the way I think about commits
  - 333c 7y ago
    I love that one too! It's great for creating commits that address one specific thing.
    - deleted 7y ago
      [deleted]
- kragen 7y ago
  I know you're probably just trolling but I'll take the bait — I'd put all of these six before any of those three: git pull git clone git status git commit -a git push git diff I mean, the ones you mentioned are pretty useful, but if you don't have a repo in the first place, even git-log isn't going to be very useful; and if you're branching and rebasing, you probably have to commit first. (I actually prefer Magit, to the point where I sometimes run Emacs just for Magit when I'm using a different IDE.)
  - 333c 7y ago
    I'm not trolling, and to assume that I am doesn't exactly "assume good faith." [0] The comment I replied to says: > Like they know enough to commit and push but that's about it. In that vein, I was suggesting what I consider to be the most basic git commands outside of the "clone, commit, push" workflow. [0]: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    - kragen 7y ago
      Oh, I didn't know you meant to imply that qualifier; I was responding only to what you said, which was absurd, not what you meant, which I now see was reasonable.
- nojvek 7y ago
  Things that really helped me understand git as a tree of references. Git reset —soft and git reset —hard Git cherry-pick Git rebase Git reflog Git stash Understanding this makes you able to manipulate branches and commits like a wizard. Once I learnt those, I can get myself out of the hairiest git problems.
RangerScience 7y ago
Absolutely. When I get people into learning Git, I start with the obvious (checkout, commit) move to the essential (branches, forks) and then usually say "When you're comfortable with that, start playing around with rebase. When you get into trouble with that, come talk to me again, because that's the key learning moment." I've learned more messing up when using fancy git rebase stuff than any tutorial.
- james_s_tayler 7y ago
  O'Reilly have a free book on Git that is amazing. I find this to be the perfect level of detail. Easy to enough to read in a short enough time, detailed enough to grasp the magic under the hood. https://www.oreilly.com/library/view/git-pocket-guide/9781449327507/ch01.html https://www.oreilly.com/library/view/git-pocket-guide/978144...
mooreds 7y ago
Ha, I just did a talk and asked how many people knew about git bisect. No one. I found this zine (not free) to be helpful: http://ohshitgit.com/ http://ohshitgit.com/
Jsharm 7y ago
Yes, and in the vein of this git became way less scary after learning how it works this course helped a lot (unfortunately paid but a lot of businesses have a licence - https://www.pluralsight.com/courses/how-git-works https://www.pluralsight.com/courses/how-git-works). I also use magit (https://magit.vc/ https://magit.vc/) - inside spacemacs (http://spacemacs.org/ http://spacemacs.org/)

by augbog 7y ago

Honestly I still find a lot of engineers don't know git properly. Like they know enough to commit and push but that's about it. It really helps to understand everything git has to offer.

333c 7y ago

The three most important basic git operations to know (in my opinion) git checkout -b git log git rebase -i

jimpudar 7y ago
I also find git blame extremely useful, along with code exploration tools like DeepGit [0] [0] https://www.syntevo.com/deepgit/ https://www.syntevo.com/deepgit/
dwoot 7y ago
I'll have to add `git reflog` for instances where you've felt that you've completely screwed up something as one can always move back to a previous state. I think this is essential. A useful one that I'll add is what I call the sword command: `git log -S<word>` This one allows one to list commits that contain a particular change. This has been useful in tracking down old changes
btilly 7y ago
I strongly prefer git merge over git rebase. Using rebase results in a cleaner history and simplified workflow in many cases. However it also means that when you have a disaster, it can be truly unrecoverable. I hope you have an old backup because you told your source control system to scramble its history, and you don't have any good way to back it out later. For those who don't know what I mean, the funny commit ids that git produces are a hash signifying the current state of the repository AND the complete history of how you got there. Every time you rebase you take the other repository, and its history, and then replay your new commits as happening now, one after the other. Now suppose that you rebased off of a repository. Then the repository is rebased by someone else. Now there is no way to merge your code back except to --force it. And that means that if your codebase is messed up, you're now screwed up with history screwed up and no good way to sort it out. That result is impossible if you're using a merge based result. The cost is, though, that the history is accurately complicated. And the existence of a complex history is a huge problem for useful tools like git bisect.
- 333c 7y ago
  I work on a small open source project. Our master branch is protected from force pushes, and I only use rebase on personal branches for features or bug fixes. It's very nice if I'm planning to merge several commits but I need to fix something in one or more of them. I agree that rebasing should not happen in the main branch(es) of a repo.
- jonahx 7y ago
  Linus on rebase: https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html https://www.mail-archive.com/dri-devel@lists.sourceforge.net...
- james_s_tayler 7y ago
  I don't know. Since git uses content-based addressing, you can't actually alter any commit, only create new ones. And orphaned commits don't get garbage collected for like 30 days even if you explicitly tell git to clean things up. So, the original stuff will still be there. It might just not be obvious how to access it. Part of the commit is the reference to zero or more parent commit object ids. So, if you find the old commit, it still has it's history intact. `git log -g` is a handy command to see a composite git log that travels across branch changes. I do get what you mean though. You effectively create new commits with an alternate view of history. I don't get quite why/how that causes a situation in which the code can't be merged? I don't rebase much, I prefer merging. Is there any resource that can explain why rebasing might be dangerous like that? In general if branches diverge too far then you have difficulties merging no matter which strategy you use and sometimes if it diverges too far it just becomes hopeless. Mostly though if you are working in a team, commit daily and merging/rebasing frequently it should present fairly few problems. I find I never run the actual command git bisect. I just do `git log --decorate --oneline --graph` and eyeball a good commit to start from and then basically do it by hand using commit messages to aid in making reasonable guesses as to where to try but following the basic binary search philosophy. Works well enough even with a complex history.
  - btilly 7y ago
    Here is an example of how to create a problem. You rebase your private branch off of a shared master and pull in other people's commits. Someone else pushes out their rebased version using force. More commits are made on top of the other people's commits, including reversing some bad commits. You try to rebase off of the shared master. In your last rebase, you are trying to replay all of the commits in your history that are not in the remote history. However git does not understand which local commits are from you and not pulled in on the previous rebase. It therefore tries to play them on top of the remote master if it can make sense of them. Which means that you bring back the reversed commits. You might find conflicts in code that you have not touched. You resolve them as best you may. And now you've got the definitive version of what happens, and no way with the screwed up history to figure out why it is going to go wrong. Then you force commit because that is how a rebase flow works..and everyone is screwed. I agree on branches diverging too far. Merge early, merge often. If you never run the command to git bisect, you should try it. What it's for is finding the random commit that recently broke a piece of functionality that nobody realized would break. Because nobody realized it, the log messages will say nothing useful. And you don't need to figure out where the change is - just write a test program for the breakage, run git bisect, and look at the offending commit.
bshacklett 7y ago
`git add -p` changed the way I think about commits
- 333c 7y ago
  I love that one too! It's great for creating commits that address one specific thing.
  - deleted 7y ago
    [deleted]
kragen 7y ago
I know you're probably just trolling but I'll take the bait — I'd put all of these six before any of those three: git pull git clone git status git commit -a git push git diff I mean, the ones you mentioned are pretty useful, but if you don't have a repo in the first place, even git-log isn't going to be very useful; and if you're branching and rebasing, you probably have to commit first. (I actually prefer Magit, to the point where I sometimes run Emacs just for Magit when I'm using a different IDE.)
- 333c 7y ago
  I'm not trolling, and to assume that I am doesn't exactly "assume good faith." [0] The comment I replied to says: > Like they know enough to commit and push but that's about it. In that vein, I was suggesting what I consider to be the most basic git commands outside of the "clone, commit, push" workflow. [0]: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - kragen 7y ago
    Oh, I didn't know you meant to imply that qualifier; I was responding only to what you said, which was absurd, not what you meant, which I now see was reasonable.
nojvek 7y ago
Things that really helped me understand git as a tree of references. Git reset —soft and git reset —hard Git cherry-pick Git rebase Git reflog Git stash Understanding this makes you able to manipulate branches and commits like a wizard. Once I learnt those, I can get myself out of the hairiest git problems.

RangerScience 7y ago

Absolutely. When I get people into learning Git, I start with the obvious (checkout, commit) move to the essential (branches, forks) and then usually say "When you're comfortable with that, start playing around with rebase. When you get into trouble with that, come talk to me again, because that's the key learning moment." I've learned more messing up when using fancy git rebase stuff than any tutorial.

james_s_tayler 7y ago
O'Reilly have a free book on Git that is amazing. I find this to be the perfect level of detail. Easy to enough to read in a short enough time, detailed enough to grasp the magic under the hood. https://www.oreilly.com/library/view/git-pocket-guide/9781449327507/ch01.html https://www.oreilly.com/library/view/git-pocket-guide/978144...

mooreds 7y ago

Ha, I just did a talk and asked how many people knew about git bisect. No one. I found this zine (not free) to be helpful: http://ohshitgit.com/ http://ohshitgit.com/

Jsharm 7y ago

Yes, and in the vein of this git became way less scary after learning how it works this course helped a lot (unfortunately paid but a lot of businesses have a licence - https://www.pluralsight.com/courses/how-git-works https://www.pluralsight.com/courses/how-git-works). I also use magit (https://magit.vc/ https://magit.vc/) - inside spacemacs (http://spacemacs.org/ http://spacemacs.org/)