Let’s start by analyzing the names?
- staging area: area to cast
In this part, you’re putting together a cast, but you don’t have it yet. You are still calling the "actors" who will "participate in the play", the significant changes you want to put into posterity
- commit: the closest I can translate comes from your substantive form: commitment, or commitment
In that part, you are ready to seal a commitment to eternity. With all that has been listed, you have put the important pieces into play and are ready to make a commitment. Hence, commit I believe it can be translated as the reflexive verb "commit".
There are other places to use commits, even without clear translation. And one of the main is in database (I will get to the point where the git
is a specific use database, leaves it hanging for a while). You can do all the work in the database without making use of commits, which in turn is the final step of a transaction? Of course you can! But this offers risks.
By the way, it has databases that do not offer other means of data updates than by transaction and closing in commit, like the sqlite. If you do not make use of this feature explicitly, it encompasses each DML operation that results in data changes within a begin transaction; ... seu update/insert/delete ... ; commit
automatically.
How does the transaction work in the database? Basically in it you call all the actors, which are manipulations of data and/ or structure, and then happily closes an appointment or gives back and back everything rolling (roll back).
In this sense, the transaction acts as an area to list changes and make a commitment.
I quoted above that the git
is a specific end database. It is not a relational database or Nosql, it is a database based on changes of text segments (or binaries, but itself was made for texts, binary is almost always marked as complete change). It simply stores the creation history of the documents and also the steps they have taken to reach another state.
In the case of git
, the repository is understood as a single entity of knowledge, but may contain several documents. Sometimes a document change requires another to be so (for example, extracting a function from a source file by generalizing it to another source file). So it’s natural that for change to be atomic, it needs to really occur in 2 or more corners at the same time. Without this guarantee, you could have changes that would make information that needs to be shared across multiple documents inconsistent.
Well, then to group these changes there is the commitment for your part. Your commitment consists of a series of deltas (or document changes), your signature (name/email) and a message to indicate what you are committing to. Yeah, right now, you married the code, congratulations. But know that there is no divorce, eternal commitment.
If there was no area to list, you could seal a commitment with a set of deltas whenever you feel the need. But, there is no divorce... what if you were just preparing? Well, in that case, you would make a potentially wrong commitment. And we don’t want to keep mistakes beyond eternity, it’s not even?
Here comes the area to list. You are not yet ready to make the commitment, but have started to list the important things. Of extra features, you could use the stash to put under the carpet changes that are not listed to see if they are atomic by itself, or if it could have done differently. There is also the case that the @Marcel Felipe replied, in which, after "soiling" your desktop, you do not seal a commitment, but two or more. I myself often do as Marcel said and select the set of lines needed for the desired change, without worrying about listing the entire file.
So back to the core of the question: What is the usefulness of the area to list? It is useless even?
It serves so that you can make commitments without future regrets (or almost that...). It also allows you to mound gradually its commitment, its changes. Additionally, you can also use it to validate the changes you want to commit to.
Yeah, I know, there’s the git commit --amend
, but it looks more like a "post-nuptial pact", and it should not be abused too much when your commitment became public, when you pushed into the remote the changes you think necessary.
If it were, it wouldn’t exist, right?
– Maniero
Right, and I do, but I don’t understand, I’d like to understand :(
– Allan Dantas
The commits in Git are permanent, so it’s interesting an area so you can prepare everything calmly and carefully before you finally submit the changes or simply change.
– Giovanni Nunes
And because the job repository cannot be used for this ? I can do in it everything that can be done in stating area, correct ?
– Allan Dantas
@Allandantas on this comment of "if it is possible to do in Y, why exist X?", what you did was a fallacy. Assembly is Turing complete, so any and all computations can be done in pure Assembly. Why then is there C?, or Java? , or Python? since they would just be redundancy against Assembly which is complete? And why Assembly if I can do it right in machine language which is the ultimate destination of Assembly? Assembly is very valued, we should all write programs with butterflies flapping wings
– Jefferson Quesado
What @Jeffersonquesado meant to say is that it takes more work, Staging is a mechanism that protects what is not yet definitive without you having big worries more laborious or that can go wrong if you forget something. You can choose to do on hand and take risks or can use the useful mechanism.
– Maniero
@Jeffersonquesado sincerely, I believe that the fallacy is yours - what Allan asked, and the example he gave are very simple: if one thing replaces all the functionalities of another, they are supposedly interchangeable in these issues - c, java and python all include a number of features that are not ready to be used in Assembly, even though they can be rebuilt - so the comparison is not valid; apparently staging area offers a feature that without it we would not have - what functionality is this?
– Daniel
Exact @Blogueira, for your post: "apparently staging area offers a feature that without it we wouldn’t have - what functionality is that?" Some studies have shown me that yes, that is a fact. Staging offers many more features, interestingly I found vast English material on the subject (articles and even stack overflow posts in English). Now I understand, I will answer the question soon, compiling all my understanding. In the meantime I have an excellent article on the subject: http://gitolite.com/uses-of-index.html
– Allan Dantas
Most of the time I use
git -commit -am "mensagem"
so you don’t have to stagger the changes, if you do it this way it’s like a staging area doesn’t exist. But sometimes I use it to "commit" specific changes without including some project files that for that commit is unnecessary.– Marcio Rodrigues
@Marciorodrigues I don’t particularly like this strategy. I abhor my personal use of
git commit -a
, even more so because I make many changes in many points I don’t want them to go up (like changing the database I’m testing in). I’m also very much in favor of revisiting commits, so every commit for me should be a unique, easy-to-understand story, preferably in an atomic way. Out of curiosity, your projects are in what language?– Jefferson Quesado
I hate mine, too, but I put the right messages, rsrs. For those who do not think it is necessary to use staging (I use it from time to time) this command would already solve. In GIT work with Delphi, Postgresql scripts, JSON and markdown.
– Marcio Rodrigues
Remember that other versioning systems like, for example, in SVN, there is no Staging, in this case there is a change in work mentality,(where we can only work on a single commit at a time) @Jeffersonquesado considers Staging so religious, because it makes multiple changes, in this case it cannot think differently, now who usually works a little closer to the mentality of the SVN does not have such a religious vision of Staged. git makes both workflows possible (by staged and direct commit) it’s up to the user to choose the best mode for them.
– Allan Dantas
@Marciorodrigues in my case is mostly Java and Bash. Sometimes markdown too, but little compared to the other two. Well, I’m extremely careful and suspicious in my own commits, I think I only do this with a certain amount of security in the initial project commit
– Jefferson Quesado
@Allandantas in SVN, as it is centralized, it was thought in a different context from the commit. It is so much that SVN is in the style "merge before commit", while git and Hg (and others distributed) are more focused on "merge afete commit". SVN engagement is much more serious than git. At worst, if in git you destroy the history, it’s easy to rewrite before publishing. The SVN way of committing is also reminiscent of that end-of-day activity where you select what you need to rush up, while git allows for something more gradual, which can last for days...
– Jefferson Quesado
In fact, GIT allows for the creation of much better structured and thought-out logic packages compared to the SVN working mode, and much of this comes from the deployment of Staged. But I believe that to abhor direct commit so rigorously is to keep yourself in a bit of a cast (of course it all depends on how each one works), in their work style so I’ve noticed Staged is indispensable, however certain situations may arise where skipping the preparation area is the smartest action, if not why there would be this possibility in GIT, do not think ?
– Allan Dantas
@Allandantas I think there are specific cases. But still, it’s a beautiful waste of potential
– Jefferson Quesado