This is a series of posts about using Git. You can read the previous entries at:

Tracing Our Steps (Part 1)
Tracing Our Steps (Part 2)
Tracing Our Steps (Part 3)

Last time, we got an ssh key configured to clone our git repo and committed our first change! Let's keep going!

Pushing Changes & Pulling Updates

1. Push your changes to the remote repository: It's time to make your changes known to the remote repository. To do this, we'll use git push. This command tells Git to send our commits to the remote repository on GitHub.

2. Verify your changes: Your changes are now live in the remote repository! You can verify this by visiting your repository on GitHub and opening the README file. You should see the sentence you added there.

3. Understanding the pull command: Now, if we flip the situation around and imagine that someone else has made changes to the remote repository, you'd want to reflect those changes in your local repository. That's where git pull comes into play. It fetches and downloads content from your remote repository and immediately updates your local repository to match that content. This allows you to work with other people asynchronously.

It's a good habit to begin any working session in a git repository by git pulling to get any changes so you're not working on outdated information!

Maybe Some, Maybe All

Remember when we used the git add command to "stage" our changes? Let's dive into that a bit.

What if you didn't want to add all the files you've changed? That's what staging is built to handle. Essentially, it's a buffer where git stores the changes you intend to include in your next commit.

When you modify a file, git notices, but these changes initially sit in a 'Modified' state. They're not immediately ready to be included in a commit. You tell git when you're ready to stage changes with the git add command. This essentially says, "These changes, I've reviewed and approved. They're ready for the commit."

The Staging Area's purpose is to give you control. By staging changes, you review and confirm exactly what will be included in your next commit. It's useful when you have multiple changes across different files that you want to commit separately for clarity.

1. Pull new changes: We're not collaborating with anyone yet but trust me, building this habit early will save a lot of time by avoiding conflicting changes! Run the git pull command.

2. Try creating a new file: Create a new file in your local repository, let's call it example.txt. You can do this by typing echo "This is an example text file." > example.txt in your terminal.

3. Modify the README file: Open up the README file and append a new line to it. You could say something like, "This project now includes an example text file."

4. Stage the changes separately: Now, we're going to stage these changes separately. First, add the changes in example.txt by typing git add example.txt in your terminal. This tells Git that you want to include updates to this file in the next commit.

5. Commit the first change: Now, let's commit the changes you've made to example.txt by typing git commit -m "Created example.txt".

6. Stage the second change: Next, stage the changes to the README file by typing git add README.md in your terminal.

7. Commit the second change: Commit these changes by typing git commit -m "Updated README to reflect addition of example.txt".

8. Push the changes: The final step is to share these updates with your remote repository. To do this, type git push into your terminal. This will 'push' your commits, along with their descriptive messages, to the remote repository on GitHub.

9. Confirm the push: Go ahead and visit your GitHub repository in your web browser. You'll see your commits, along with the messages you wrote, visible in the commit history of the repository. If you navigate to your README file and example.txt, you'll also see the changes you made reflected there.

The Stage Is Your World

You've separately staged and committed changes to two different files in your repository. This process is key when working on larger projects where you want to commit different pieces of work separately.

You can use this to tell a clearer story of what changes you're making using your commit messages. This comes in especially handy when you need to have someone review the work you did.

While you're working, you can get caught up in the flow state and make a plethora of changes to lots of files. Subdividing and grouping those changes using the staging area and descriptive commit messages can signal to another human what you were trying to accomplish with each set of changes.

Next time, we'll tackle what happens when you need multiple people working on a project simultaneously. If everyone is committing their changes and pushing their work, there's a chance that conflicting changes will occur to the same lines of text. Git was specifically designed to handle this exact situation!

Until next time,

Keep learning and keep growing!

Darrell