Software development is a messy and intensive process, which in theory, should be a linear, cumulative construction of functionalities and improvements in code, but is rather more complex. More often than not it is a series of intertwined, non-linear threads of complex code, partly finished features, old legacy methods, collections of TODO comments, and other things common to any human-driven and a largely hand-crafted process known to mankind. Git was built to make our lives easier when dealing with this messy and complex approach to software development. Git made it possible to work effortlessly on many features at once and decide what you want to stage and commit to the repository. The staging area in Git is the main working area, but most of the developers know only a little about it. In this article, we will be discussing about the staging area in Git and how it is a fundamental part of version control and can be used effectively to make version control easier and uncomplicated. What is the Staging area To understand what the staging area is, let’s take a real-world example - suppose that you are moving to another place, and you have to pack your stuff into boxes and you wouldn’t want to mix the items meant for the bathroom, kitchen, bedroom, and the living room in the same box. So, you will take a box and start putting stuff into it, and if doesn’t make sense, you can also remove it before finally packing the box and labeling it. Here, in this example, the box serves as the staging area, where you are doing the work (crafting your commit), whereas when you are done, then you are packing it and labeling it (committing the code). In technical terms, the staging area is the middle ground between what you have done to your files (also known as the working directory) and what you had last committed (the HEAD commit). As the name implies, the staging area gives you space to prepare (stage) the changes that will be reflected on the next commit. This surely adds up some complexity to the process, but it also adds more flexibility to selectively prepare the commits as they can be modified several times in the staging area before committing. Assume you're working on two files, but only one is ready to commit. You don't want to be forced to commit both files, but only the one that is ready. This is where Git's staging area comes in handy. We place files in a staging area before committing what has been staged. Even the deletion of a file must be recorded in Git's history, therefore deleted files must be staged before being committed. What are git commands for the staging area git add The command used to stage any change in Git is . The command adds a modification to the staging area from the working directory. It informs Git that you wish to include changes to a specific file in the next commit. However, git add has little effect on the repository—changes are not truly recorded until you execute git commit. git add git add git add
 [project*]  <------------  project*
                               ^
                               | modify with editor
                               |
  HEAD            .         project
    |             .
    |             .
    |             .
  HEAD~1          .
    |             .
    |             .
    |             .
                  .
  .git            .     working directory
(history)         .      (files we see) The common options available along with this command are as follows: You can specify a from which all changes will be staged. The syntax would be as follows: <file> git add <file> Similarly, you can specify a <directory> for the next commit: git add <directory> You can also use a to add all the changes from the present directory, such as the following: . git add . git status command is used to check the status of the files (untracked, modified, or deleted) in the present branch. It can be simply used as follows: git status git status git reset In case, you have accidentally staged a file or directory and want to undo it or unstage it, then you can use the command. git reset git reset
 [project*]  ------------>  project*



  HEAD            .
    |             .
    |             .
    |             .
  HEAD~1          .
    |             .
    |             .
    |             .
                  .
  .git            .     working directory
(history)         .      (files we see) It can be used as follows: git reset HEAD example.html git rm If you remove files, they will appear as deleted in , and you must use to stage them. Another option is to use the command, which deletes and stages files in a single command: git status git add git rm To remove a file (and stage it) - git rm example.html To remove a folder (and stage it) - git rm -r myfolder git commit The command saves a snapshot of the current staged changes in the project. Committed snapshots are "secure" versions of a project that Git will never alter unless you specifically ask it to. git commit HEAD            .         project
    |             .
    |             .
    |             .
  HEAD~1          .
    |             .
    |             .
    |             .
  HEAD~2          .
    |             .
    |             .
    |             .
                  .
  .git            .     working directory
(history)         .      (files we see) Git may be considered a timeline management utility at a high level. Commits are the fundamental building blocks of a Git project timeline. Commits may be thought of as snapshots or milestones along a Git project's history. Commits are produced with the git commit command to record the current status of a project. Git Snapshots are never committed to the remote repository. As the staging area serves as a wall between the working directory and the project history, each developer's local repository serves as a wall between their contributions and the central repository. The most common syntax followed to create a commit in git is as follows: git commit -m "commit message" Conclusion To summarize, is the first command in a series of commands that instructs Git to "store" a snapshot of the current project state into the commit history. When used alone, moves pending changes from the working directory to the staging area. The command examines the repository's current state and can be used to confirm a promotion. To undo a , use the command. The command is then used to add a snapshot of the staging directory to the commit history of the repository. git add git add git status git add git add git reset git commit I hope this article was helpful. Do let me know if you have any feedback or suggestions for this article. Keep reading!

Keep

Understanding Multiprocessing and Multithreading in Python

11 Tips And Tricks To Write Better Python Code

Read My Stories

Portfolio

Too Long; Didn't Read

Make resilience your competitive advantage

Understanding the Staging Area in Git

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Asynchronous Programming in Python using Async IO

10 GitHub Repositories to Follow

3 Easy Steps to Change Main Git Branch on Heroku

28 Stories To Learn About Markdown

194 Stories To Learn About Git

Asynchronous Programming in Python using Async IO

10 GitHub Repositories to Follow

3 Easy Steps to Change Main Git Branch on Heroku

28 Stories To Learn About Markdown

194 Stories To Learn About Git

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps