|add||Add changes from the working tree to the index.|
|commit||Make a new commit from the changes in the index and move the branch and HEAD sticky notes to the new commit.|
|restore||Throw away changes you've made by reverting to a version of the code from the index or the checked out commit.|
|reset||Move the branch and HEAD notes to a specific commit and check out the version of the code at that commit.|
|checkout||Move only the HEAD note to a specific commit and check out the version of the code at that commit.|
|branch||Create a new branch sticky note at the checked out commit (the commit with the HEAD sticky note.|
|merge||Take all changes from the given branch relative to your current branch, and create a new commit that has both versions of the code as parents.|
In order to make new commits, the HEAD note must be at the same commit that has a branch note. When you make a new commit, both the HEAD and branch notes are moved to the latest commit. The reset command allows you to move the HEAD and branch notes to a commit you already made.
S Fox wrote:the git simulator allows me to detach the head from the branch and i am able to do commits while the head is attached directly to a commit node without any branch tag on it. is that not supposed to be possible in the real world?
also from my experimenting on that site, it seems that doing "branch -f" is exactly the same thing as doing a rebase ?
as long as all the commits are on the branch, the order that the commits are in should not matter at all right?
also i don't quite understand how merging branches works yet. lets say i have two branches of a simple hello world app, and in one branch it says "hello" and in the other it says "goodbye" how would merge work in that kind of situation?
Stephan van Hulst wrote:So making commits in a detached HEAD state is useful when you want to experiment a little and then 'throw away' your work when you switch back to a real branch. It's not advisable to perform experiments this way though.
S Fox wrote:i understand that you can undo a commit, but can you undo a merge or rebase?
undoing a branch -f should be easy since it just moved a tag, right?
how about undoing the deletion of a branch?
or undoing a prune?
i don't really have a sense of how it impacts the underlying codebase. it's just a bunch of dots in the graph that i am pushing around it doesn't show what happened to any code.
this is why it appears to me that "branch -f" is the same thing as doing a rebase.
so i guess i will start experimenting with the real one, i'll make a copy of my project so i don't accidentally destroy it