Tools: Understanding Git in a simple and elaborate way.

Step 2: Setting Up Git (One-Time Setup) ## Step 7: Pushing Code to GitHub ## Step 8: Pulling Updates From GitHub ## Forgetting to commit ## Not pulling first ## Using unclear commit messages ## Uploading sensitive files ## Git Command Cheat Sheet *Understanding Git Version Control: How I Push, Pull, and Track Changes * When I first started programming, I kept overwriting files and losing progress. Sometimes I would break my project and have no way to go back. That’s when I discovered Git — a version control system that completely changed how I manage code. In this article I will explain how I track changes, commit, push, and pull code using Git in a simple way. What Is Git and Why Do I Use It? Git is a tool that tracks changes in my project files over time. I use it to: This is the basic workflow I follow every day: Step 1: Installing Git Before using Git, I make sure it’s installed. I check by typing on the terminal on my computer If Git is not installed, I download it from: The first time I use Git, I tell it who I am for instance my name is chege and my email is [email protected] git config --global user.name "Chege" git config --global user.email "[email protected]" This information is key as it appears in my commit history so others can see who made each change. Step 3: Creating or Cloning a Repository. In this step there are two options available Option 1 — Initialize Git in My Project If I already have a project folder, I open it and run: This creates a hidden .git folder that starts tracking my project. Option B — Clone an Existing GitHub Project If the project already exists online, I use: git clone https://github.com/username/repository-name.git This downloads the project directly to my computer. Step 4: Checking File Status (Tracking Changes) Whenever I modify files, I check what Git sees by running: Step 5: Staging Changes Before saving changes permanently, I move them to the staging area. Staging lets me choose exactly what I want to include in my next commit. ** Step 6: Committing Changes (Saving a Snapshot)** A commit is like taking a snapshot of my project at that moment. I save my changes using: git commit -m "Added homepage layout" How to Write Good Commit Messages Clear messages help future me (and teammates). After committing, I upload my code to GitHub using push: Here’s what this means: Now my code is backed up online. When someone else updates the project or when I switch devices I use pull: This downloads the newest changes and merges them into my local project. Viewing Project History To see all saved versions of my project, I run: *Understanding Branches * Branches allow me to work on new features without breaking the main project. Creating and Switching to a Branch Instead of two commands, I usually use one: git checkout -b new-feature When the feature is ready, I merge it back: git checkout main git merge new-feature Some beginner mistakes that I learned to avoid I always commit before pushing. I pull updates before starting work to avoid conflicts. Clear messages save time later. I never commit passwords, API keys, or .env files. Learning Git completely changed how I code. I no longer worry about losing progress, breaking projects, working with teammates, making mistakes. This is because Git lets me track, restore, collaborate, and grow confidently Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse - Save different versions of my code - Restore old working versions - Collaborate with teammates - Upload my projects to GitHub safely - I edit files on my computer - I stage the changes - I commit them. This is like saving them as a snapshot. - I push them to GitHub - I pull updates when needed - Which files were changed - Which files are staged - Which files are new ** Understanding File States** - Red files → Changed but not staged - Green files → Ready to be committed - Keep it short - Be specific - Describe what changed - origin → The remote GitHub repository - main → The main branch of the project - Author names - Messages It helps me track progress and debug issues. - Creates a branch - Switches to it immediately