The staging area holds changes that you have made to your source files and have staged (using "git add") but have not yet committed. It allows you to collect all the changes that you want to commit together in one place before committing. Most of the time it's a bit of an unnecessary step as you'll just want to commit all your changes (which you can do with "git commit -a") but sometimes you may have made changes that do not logically belong together in a single commit. In this case you can stage only certain changed files (using "git add") while leaving other changed files unstaged. When you do a "git commit", only the staged changes will be committed. You can use "git status" to see which files contain changes and whether or not they are staged for commit.
The staging area even offers more levels of adding "things":
For example: Having a file, where you fixed two separated bugs without commiting, you are able to stage only the hunks/lines concerning the fix of the first bug for your first commit. After this you might add the remaining changes (second bugfix) to the staging area - and perform a second commit.
Consider Statig area as a container to collect all logically mated changes for your next commit from your unordered unrelated uncommitted changes in your sandbox ...
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot