🐙
Git Developer Guide
About
  • Overview
  • Scope of this book
  • Table of Content
  • 🐢Introduction to Version Control
    • What is Version Control?
    • Overview of git and it's benefits
    • Setting up Git on Different Platforms
  • 🍼Git Fundamentals
    • Initialising a new Git repository
    • Understanding the Git Workflow
    • Committing Changes and Writing Good Commit Messages
    • Viewing and Navigating Commit History
    • Git Basics - Practice Scenarios
      • Initialising a Git Repository
      • Committing Changes
      • Exploring Commit History
      • Amending and Undoing Commits
  • 🦕Working With Git
    • What is Git Branch?
    • Creating and Switching Between Branches
    • Merging Branches and Resolving Conflicts
    • Best Practices for Branch Management
    • Git Workflows
    • Git Log
    • Git Stash
    • Working with Git - Practice Scenarios
      • Creating and Switching Between Branches
      • Merging Branches and Resolving Conflicts
      • Branching Strategies in a Team Project
      • Rolling Back to a Previous Version
      • Experimenting with Feature Branches
      • Working with Stash
  • 🤝Working with Remote Repositories
    • Cloning a Repository from Remote
    • Pushing and Pulling Changes to and from Remote Repositories
    • Collaborative Workflows - Forking, Branching, and Pull Requests
    • Resolving Conflicts in a Collaborative Environment
    • Collaborating with Git - Practice Scenarios
      • Cloning a Remote Repository
      • Pushing and Pulling Changes
      • Collaborative Workflow with Forking and Pull Requests
      • Resolving Conflicts in a Pull Request
  • 🏆Advanced Git Features
    • Aliases and Custom Configurations
    • Working with Tags and Releases
    • Rewriting Commit History with Interactive Rebase
    • Utilising Git Hooks for Automation
    • Advanced Git Features - Practice Scenarios
      • Creating Custom Git Aliases
      • Working with Tags and Releases
      • Rewriting Commit History with Interactive Rebase
      • Using Git Hooks for Automated Testing
  • 😎Git in Real-World
    • Managing a Project with Multiple Contributors
    • Integrating Git with Continuous Integration, Continuous Deployment (CI, CD)
    • Versioning Assets with Git LFS (Large File Storage)
    • Deploying a Web Application using Git
    • Git In Real World - Practice Scenarios
      • Managing a Project with Multiple Contributors
      • Integrating Git with CICD Pipelines
      • Versioning Assets with Git LFS
      • Deploying a Web Application using Git
  • Git Troubleshooting
    • Common Mistakes and Pitfalls When Using Git
    • Undoing Changes with Git - Reverting and Resetting
    • Recovering Lost Commits or Branches
    • Dealing with Repository Corruption or Other Issues
  • Git Best Practices and Tips
    • Creating efficient git workflows: writing clean code for faster reviews
    • The importance of clean code in collaborative development
    • Significance of consistent naming conventions & coding Standards
    • Good code documentation for better git workflows
    • Writing meaningful git commit messages
    • Atomic commits in git & it's benefits for software teams
    • Structuring code & managing dependencies for better git workflows
    • Git branching strategies for software teams
  • Conclusion & Next Steps
    • Recap of Key Concepts and Commands
    • Further Resources for Expanding Git Knowledge
    • Encouragement and Tips for Continued Learning and Practice
  • License Considerations
Powered by GitBook
On this page

Was this helpful?

  1. Git Fundamentals

Understanding the Git Workflow

PreviousInitialising a new Git repositoryNextCommitting Changes and Writing Good Commit Messages

Last updated 1 year ago

Was this helpful?

The git workflow is made up of three main areas: the working directory, staging area (index), and repository. We will also discuss the purpose and flow of changes through these areas, as well as differentiate between modified, staged, and committed files.

The Working Directory

The working directory, also known as the working tree, is the place where you make modifications to your project files. It represents the current state of your project and contains all the files and directories that make up your codebase. When you make changes to a file in the working directory, Git recognises it as a modified file.

For example, let's say you have a file named "script.py" in your working directory. You can open this file in your favorite text editor or IDE and make changes to the code.

The Staging Area (Index)

The staging area, also referred to as the index, acts as a middle ground between the working directory and the repository. It is a place where you can selectively choose which changes you want to include in the next commit. Think of the staging area as a snapshot of your project at a specific point in time.

To add changes to the staging area, you need to use the git add command. This command allows you to specify the files or directories that you want to stage for the next commit. Once you add a file to the staging area, it becomes a staged file.

For example, let's assume you modified the "script.py" file in the working directory. To stage this change, you would run the following command:

git add script.py

The Repository

The repository, also known as the Git repository or simply repo, is where Git permanently stores your project's history. It contains all the committed versions of your files and directories, along with the associated metadata. The repository is typically stored in a hidden directory named .git at the root of your project.

When you are satisfied with the changes in the staging area and want to record them as a new version, you need to create a commit. A commit represents a logical unit of change and serves as a checkpoint in your project's history. It captures the state of the staging area at the time of the commit and includes a commit message that describes the changes.

To commit the staged changes, you can use the git commit command followed by a commit message. For example:

git commit -m "Add script.py"

Once the commit is created, the changes are stored in the repository, and the staging area becomes empty again. The committed files are now considered committed files, which means they are part of the project history.

Modified, Staged, and Committed Files

It's important to understand the differences between modified, staged, and committed files in the Git workflow:

  1. Modified files: These are the files that have been changed in the working directory but haven't been staged or committed yet. They represent the current state of your project's files.

  2. Staged files: These are the files that have been added to the staging area using the git add command. Staged files are ready to be included in the next commit and represent the changes you intend to commit.

  3. Committed files: These are the files that have been included in a commit using the git commit command. Committed files are part of your project's history and are stored in the repository.

It's worth noting that you can modify multiple files simultaneously, stage specific changes from different files, and commit multiple changes as a single unit. Git provides flexibility in managing your project's changes.

File changes flow through these areas, from modifying files in the working directory to staging them in the index and finally committing them to the repository

🍼