4 ms·
> E.g., rebasing. I don’t completely understand what it is supposed to achieve. I recognize that this is just one example of probably many things you dislike a
by Snild 5y ago
> E.g., rebasing. I don’t completely understand what it is supposed to achieve.
I recognize that this is just one example of probably many things you dislike about git, and I will not be able to change your mind about it, but:
Rebasing is essentially the user saying "actually, I wanted to make these changes on top of this different base". This is useful if you perhaps started some work on the wrong branch, or just want to test your change on top of the most recent upstream code.
> Nothing makes sense.
I think there are two key realizations to understanding git:
1. It's a directed acyclic graph. That's a very nice data structure to think and reason about.
2. Everyone can have their own version of this graph, so committing a change and sharing it with others are two different operations (and fetching others' changes is yet another).
With those things in mind:
* git rebase copies an arm of the graph and grafts it onto a different starting node
* git cherry-pick copies an arbitrary node in the graph
* git push shares your local additions to the graph with others (usually through a server)
* git fetch updates your local graph (usually from a server)
* git merge joins two arms of the graph, so that one can enjoy the changes from both at the same time
- ghusbands 5y agoGit's graph is of complete versions, but much of your text talks about it like it's a graph of changes. git rebase analyses an arm of the graph, turns it into a set of changes, tries to work out what those changes would look like if they were attached elsewhere, and then produces that. It doesn't sound as simple that way, but it's important to keep in mind that git does not track changes and instead rederives them continually.
- Snild 5y agoYou are technically correct; the best kind of correct. Writing as if they were changes is a little sloppy, though convenient.