Git workflow

When working with Git the normal workflow starts with making changes to files, or adding new files, or deleting old files that are no longer needed. Once we are done making changes, we add these files to the Staging Area. If we are satisfied with the changes, we will commit those changes to the Repository.


Creating a commit is like taking a snapshot of our project. These snapshots are permanently stored in our repository. If there are changes that we don't want to add to the snapshot, we can un-stage them and add them to a later snapshot.


To add a file to the staging area we use

git add file_name.ext

Once we've reviewed the files and are sure that we want to take a snapshot, we use

git commit -m "commit message"

Every commit should contain a meaningful message that explains what changes were made in that snapshot.

Git workflow 1

Once we commit some changes the Staging Area does not get emptied. Think of it as the staging server of an application. Once we release a new version, the live and staging versions are the same, but that does not mean that there is no staging version.


If we make some new changes to a file, we need to stage the files again. The same is true when deleting files. If we delete a file from our working directory, we need to stage the deletion. To do it we use

git add name_of_the_deleted_file

Then we can permanently record this deletion by committing it with the following command:

git commit -m "commit message"

Each commit contains:

  • A unique ID that gets generated by Git
  • The commit message
  • Date and time of the commit
  • Author
  • A complete snapshot of the project at the time the commit was created

Git can store the complete project snapshot because it compresses the files and doesn’t store duplicates.