111–120 of 273 posts
Here is my personal recommendation for getting more comfortable with git. Use "git status" a lot. Everytime you do something in git, and before you do something, do a "git status" and see what you change with your commands. And what you didn't change. Also "git log".
has nice color coding around the date, person committing, commit hash, and message.
Earlier quoted context omitted.
So I have a solid mental of git, and I understand the theoretical need for the staging area. However, I find the occasions for using the staging area in practice are few and far between, for the simple reason that I can't test and execute the code that's in the staging area without also having the code from the working directory also be there. It feels like after having partially staged some of my working directory,…
You never amend commits or rebase locally before pushing? I rebase before pushing almost every time. Git’s workflow wouldn’t even be sane without the staging area. This is what allows you to fix mistakes and make your work presentable for remotes.
Earlier 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?
EDIT: Now that I think about it, I also have several repos where I have changes that I never intend to ever commit them, because they are development conveniences for me personally.
- show what happens as you add commits to a branch - show that branches are just pointers to commits - show what creating new branches looks like, i.e. creating a new pointer - show what merging looks like (a new merge commit is added, or else fast-forward merge and that the branch pointer just moves) - show what happens if you don't rebase (i.e. "ugly" non-linear graph) ... then teach what rebasing does (i.e. creates new nodes and moves the pointer)
I found that building up from the ground up and illustrating graphs allowed people to conceptualize things much better. There was still some confusion once merging was introduced (what happens to those earlier commits? do we need them?) and mostly because people hadn't thought of the graph before.
Git is one of those tools where you can totally do your job just by knowing the basic commands but not really know what is happening under the surface, which I think is a testament to the tool. But, that leads people to conceptualize their own idea of what is going on... and getting it wrong and being confused when they want to do something outside of their basic toolset.
Earlier quoted context omitted.
Great idea. This kind of culture is why there are a lot of people that don't and probably never will use git.
The article is about how to get a more fundamental understanding idea on how git works, and this book demonstrates fundamental ideas on how git works. I don't see a problem in this reccomendation. If you want just a cursory knowledge of how to use git to get by, this probably not the right choice, but that's not really what this discussion is about is it?
Having taught git several times within a data science course I find two concepts especially worth extra time: WHY there is a staging area, and what is the difference between “git” and “github”.
> WHY there is a staging area I understand your second point, but I have a hard time understanding the difficulty with this part. Why is it hard for people to understand the idea of staging? You put things in a box one at a time before closing the box. Does it require more explanation than that? What do people find difficult about it?
Earlier quoted context omitted.
I will save this answer for when anyone complaints about C++ or Rust being complex languages.
How about now :) Rust and C++ are complicated languages, and that's bad. But git isn't complicated. Git is a handful of simple ideas composed in interesting ways. It looks complicated because there's a lot of porcelain commands with a lot of options, but all of them are just manipulating the same simple internals which, once understood, are clear and intuitive.
On the other hand, I've used ClearCase.
(Do not use ClearCase.)
http://ndpsoftware.com/git-cheatsheet.html#loc=workspace;
Guided tour - http://gitimmersion.com/
Earlier quoted context omitted.
> WHY there is a staging area I understand your second point, but I have a hard time understanding the difficulty with this part. Why is it hard for people to understand the idea of staging? You put things in a box one at a time before closing the box. Does it require more explanation than that? What do people find difficult about it?
So I have a solid mental of git, and I understand the theoretical need for the staging area. However, I find the occasions for using the staging area in practice are few and far between, for the simple reason that I can't test and execute the code that's in the staging area without also having the code from the working directory also be there. It feels like after having partially staged some of my working directory,…
You're adding a feature to your proggie. That involves modifying the main bits to add the feature and, say, adding a couple of interfaces to internal library modules.
Split out the changes to the library modules into separate commits---it's safe because nothing uses them, they're logically separate from the feature changes (although they don't appear to have a justification without the feature), the log will be marginally cleaner, and git bisect will have more granularity.
Here is my personal recommendation for getting more comfortable with git. Use "git status" a lot. Everytime you do something in git, and before you do something, do a "git status" and see what you change with your commands. And what you didn't change. Also "git log".
`git log` on its own (with no flags) isn't that useful, as it's missing a lot of important information. I prefer `git config --global alias.lg "log --color --graph --oneline --decorate"`. Then you can just type `git lg` and get a much more useful overview of the state of your current branch.