Is GIT Staging Area useless?

Question

I understand the workflow regarding the process that leads to a commit (working directory -> staged area -> repository), but I still can’t understand the usefulness of Staging Area in practice.

My thinking is this, I can use the working directory and I don’t need the Staging. When modifying a file (if it’s mapped) GIT records the changes, I can then make all the necessary modifications to my commit and then upload them to the repository, without having to go through Staging.

I know other version control systems work this way, but GIT is different. The end is the practical utility of Staging Area in GIT ?

Answer 1

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.

Answer 2

Understand the existence of Staging Area more like a resource than an obligation to use in Git.

It’s perfectly possible to work with Git without ever using Staging Area, and there is no problem giving it up in your day-to-day developer. But it can be very useful if you know how to use it.

The main use of it is to make you have more control which amendments you wish to commit at a time, allowing smaller commits without much extra effort for this.

Imagine you’ve made a lot of changes to various files in your project: database script, configuration files, source files, new images inserted, etc. Of course you could make a single commit with everything:

git commit -am "Funcionalidade XYZ implementada. Imagens inseridas, 
    arquivos de configuração alterados, HTML de criar, 
    editar e excluir criados. Scripts SQL inseridos para os novos parâmetros"

Well, it will be a commit gentleman with a commit message lady.

Maybe you’d like to separate the files sent to each commit better, leaving the changes made more organized:

git add config/application.yml
git commit -m "Configurações alteradas"

git add images/imagem1.jpg images/imagem2.jpg 
git commit -m "Novas imagens"

And so on and so forth.

Without the Staging Area, you would have a lot of work to do the same thing: you would need to diff the changes to save what you did, just leave what you want to send in the current commit, save the binary files in another location until you commit where they go, etc.

The Staging Area can also be used in more specific situations, such as when you are in the middle of a code implementation and some bug appears that needs to be fixed first. You can simply fix the bug in the file, make a git add only of the changed file and do the git push, without worrying about the other changes.

Answer 3

Here is an example of when staging area is useful to me:

In my day-to-day work development it is very common to receive a large demand, which needs many changes, so I open a Feature and start my work.

During my work I developed a screen (html and css) however I am still developing its functionality (javascript), at this time someone from the team asks to take a look at the layout of the new screen, IE, I need to commit only html and css, This is where staging area is useful, adding only html and css I can commit just them without having to remove my javascript code. If there was no staging area I would end up commiting the javascript together can take several bugs together.