Hacker News Reader

Comment by anamax | Hacker News Reader

> When you do a "git commit" the result sits on your machine. It goes nowhere.

Those of us who don't know git are now confused.

We're used to having "the result" on our local machine without interacting with our source control system. So, why do git users use its "commit" command to accomplish that?

We're used to "commit" meaning something like "publish". We're pretty sure that git has something similar, so we're wondering what it's called and why it wasn't called commit.

To refer to another discussion, this example makes it look like git requires more user actions to accomplish what we want to do and it uses idiosyncratic terminology. It's unclear why we'd view either of those as an improvement....

View on HN

"commit" usually (always?) means to take the changes you made and enter them into the version control system.

Git is a distributed system, where every user gets their own repository, so "commit" alters the repository on the local machine. This means you can use version control with impunity and not worry about giving bad code to colleagues. You can commit a broken work-in-progress without harming anything. You can also create branches with impunity and not have to worry about naming conflicts, polluting the space of branch names, etc. If something turns out to be a bad idea, you just zap it and nobody ever has to know.

When you reach a version that needs to go out to the wider world, you use "git push" to send it to a shared server. By default git remembers where you used "git pull" to obtain the source from in the first place, and can automatically push back to that server. (Note that I say shared server, not central server. If you want a single official server, you a free to dictate that for your project. You can also give each work group their own repository.)

> Git is a distributed system, where every user gets their own repository, so "commit" alters the repository on the local machine. This means you can use version control with impunity and not worry about giving bad code to colleagues. You can commit a broken work-in-progress without harming anything. You can also create branches with impunity and not have to worry about naming conflicts, polluting the space of branch names, etc. If something turns out to be a bad idea, you just zap it and nobody ever has to know.

I can do all those things without involving the source control system, so what do I get by involving the source control system? For example, why would I want to commit broken code? What does a local commit do for me?

In most cases, "distributed" is a necessary evil that folks work to hide, with varying degrees of success.

A local commit gives you a rich undo system.

Reply on news.ycombinator.com