This is missing pointing everyone at a phenomenal ncurses git log viewer: https://github.com/jonas/tig
And another great bit: always do `git commit -v` for verbose commit edits. Read your diffs before you commit them.
How to teach Git
161–170 of 273 posts
Re: How to teach Git
#162I disagree with this idea. The best way to learn git is to read the git book, in this order: chapters 1, 10, 2, 3, and the rest at your discretion. This way teaches you about the internals first, and if you understand the internals the rest of git is pretty intuitive. https://git-scm.com/book/en/v2
[deleted]
Re: How to teach Git
#163Earlier quoted context omitted.
This has never made sense to me. I've seen others say that they commit only parts of a file. How does this scenario start? Are you working on solving one problem, but then notice some other unrelated issue and fix that too, before committing the first change?
One common scenario is that I'm working on one problem, and in the process of solving that issue do some refactoring of related code. In this case, I want to commit the refactoring (which does not change the program's behaviour) before committing the changes that do change the program's behaviour.
I typically then send that first refactoring commit to Github (on its own branch) so that it gets full CI test coverage. And then continue working on the fix/feature while it runs.
Re: How to teach Git
#164This is missing pointing everyone at a phenomenal ncurses git log viewer: https://github.com/jonas/tig And another great bit: always do `git commit -v` for verbose commit edits. Read your diffs before you commit them.
How can anyone have a project home page without..showing me why I should use the project.
Would it have killed Jonas to include a screenshot in the README?
I'm not going to install something just because someone says it's good. I have to go multiple links deep to get taken to a Flickr gallery, and even then I'm not sure what is so good about it: https://www.flickr.com/photos/jonasfonseca/sets/721576144707...
Re: How to teach Git
#165Earlier quoted context omitted.
Because you not always want to put everything in the box (and if you do, there's a shortcut to do it), and "git commit file1 folder/folder/ * .cpp folder/folder/ * .h ..." for a complex set would be annoying and require you to mentally keep track of it from the beginning. Many beginners will start by always doing "git commit -a" and that's fine, as long as they know there's an alternative once they need it.
But why is the exceptional case the default? Surely, most of the time when you go to commit, it's all the files you've changed?
Not really. I think of my git use case at work pretty simple. I usually stash, pull down, fast-foward and then pop my stash on top. Occasionally I'll need to rebase too. Just to show I'm not a super advanced user or anything.
I'm a JS dev mainly working in React on a web app with a backend team using PHP. Often I'll be working on a branch with maybe 2 or 3 people and I often end up working on a few things at a time. Say I'm working on a feature, and I notice some bug I'll fix that and then get on with my feature. Once I go to commit I pretty much always do a 'git add . -p' and I very rarely want to add all the files I've worked on!
Even things like switching a config file to use a service like apiary where I don't want to commit my change to the config to use apiary.. Or change to my webpack config for testing, etc.
I've used Perforce, SVN and Git and the whole 'staging' area thing always felt very natural to me. Here are the files you've edited, which ones want to be commited? It gives me a second chance to go through and check everything before I've commited, and often that stops me leaving in any odd comments or debug code.
Re: How to teach Git
#166Earlier quoted context omitted.
But why is the exceptional case the default? Surely, most of the time when you go to commit, it's all the files you've changed?
Not for me! I often find myself refactoring tangential features while producing a new one. Sometimes that will even intersect in a single file. But that refactoring doesn't come with any changes relevant to the feature I am working on in my branch. So I save them for their own isolated commit(s). While this doesn't happen on every commit, it probably happens for me about every other push. The alternative is bundling…
Same for me! Webpack config changes to cache settings, config changes to hit a different API for testing, using a different database for testing. Most of these live in my staging area and get stashed and popped when I switch branches/rebase.
Re: How to teach Git
#167[deleted]
Re: How to teach Git
#168This is nice, but I'd like a 201-level handholding on git. I've been using it for 5 years and I'm still just a clone/commit/merge/(bang head)/push user yet I know there is tons more it can do that would probably make me more effective. (I'd also like to switch my team of SVN. Someday....)
My recommendations: * Git From the Bottom Up: https://jwiegley.github.io/git-from-the-bottom-up/ (PDF: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf ) (See also: "Linus Torvalds' greatest invention": http://perl.plover.com/yak/git/ ) Once your mental model matches the program, you'll be able to understand everything, hack your own solutions if necessary, etc. * Learn Git Branching: https://learngitbranching.j…
Thanks! Awesome resources! I'll add it to my post as soon as I finish reading all the answers. I'm learning a lot from you!
Re: How to teach Git
#169I've had to teach git to several people. Here is what i teach: - never force push (with exceptions) - don't use reset (with exceptions) - don't commit to master - stop immediately if git tells you, you have 200 changes Aside from that, people don't really seem to have trouble. Git is pretty functional with just add, commit, push, pull. People learn more commands as they need them. This post was humor
Hahah, once at work a guy force pushed to a branch that was just about to be merged. This almost resulted in some guys work being lost but luckily it was recovered.
This was immediately followed by another dev writing 'DO NOT FORCE PUSH' on a post-it and sticking it to his monitor :D
Edit: I meant merged not committed.
Re: How to teach Git
#170Earlier quoted context omitted.
This is so so fitting, and describe me to a "T" as well. I'd add oh-crap-I-screwed-up-so-let's-clone-the-repo-and-start-over to the list.
What can you screw up that requires re-cloning the repo rather than just a reset --hard?
Not knowing about the "reset --hard" feature? :)