If we run
git status in the terminal, we can see the current branch, likely
develop. We don’t want to make our changes directly on the main branch. This is where the magic of Git comes in. We can create a new branch to serve as our separate space to work and make changes.
You can create a new branch with:
git checkout -b <branch-name>
This will also automatically check out or switch to the new branch.
Consider best practices when naming your branch. Branches are meant to be short-lived and single-purpose. You do not, for example, want to have a branch called
cecelia-changes that you reuse for all your work.
There are likely branch name requirements at your organization or for the project. If not, you’ll want to use a convention similar to this format:
<issue-number>-<category>-<description or name>
Now on the new branch, you can make and save your changes to the code.
If you are using VS code, you can type
code . to open the current directory in the IDE. Otherwise open the project in the code editor of your choice.
To practice, you can make a small change to your
README.md file. Save the changes in your code editor.
After saving your changes, it’s a good idea to run
git status and confirm which files were updated.
git status command will confirm our current branch and show which files have been modified. You should review the changed files and ensure there are no unintended changes. Sometimes we may inadvertently alter our
package.json and need to correct it or we may need to add files to
Once you’ve confirmed the changes are correct, you will record the changes to the repository.
Checking in your changes is a three-step process. We can think of our changes like a letter we want to mail to a friend. At this point, we have a completed letter. We still need to:
- Put our letter in an envelope (add changes)
- Label and seal the envelope (commit changes)
- Drop the envelope in the mailbox (push changes)
These are represented in the next three steps. For a detailed breakdown of recording changes to a repository and the available options through the process, check out this guide from the Git documentation.
When we ran the
git status command, we saw the modified files ready to be staged. We can either add these files individually or all together.
git add <file-name>
git add .
This step is like putting the letter inside an envelope. At this point, we could add more files to be staged, just like we could add more pages to our letter because we have not yet sealed the envelope.
We then commit our changes using the command:
git commit -m "commit message here"
By using the
-m flag we can pass a message via the command line. If you prefer to use a text editor to write a longer commit message, you can just run
git commit and it will prompt a text editor to open.
Just like with our branch name, it’s important to ensure our commit messages are helpful. Your organization will likely have a standard for messages, particularly if they use a tool like semantic-release, which automatically manages which commits are associated with releases. Commit messages may also be automatically associated with issues or other tools as well. For example, here is the commit message format used by Angular.
fix($compile): couple of unit tests for IE9 Older IEs serialize html uppercased, but IE9 does not... Would be better to expect case insensitive, unfortunately jasmine does not allow to user regexps for throw expectations. Closes #392 Breaks foo.bar api, foo.baz should be used instead
After executing our command, we can confirm with
git status that there are no changes in the working directory. This means we have sealed the envelope. We can either drop it in the mailbox (AKA, push our changes) or wait until we have more envelopes and deliver them all at once! The next and final part of this series will cover pushing changes and submitting a pull request, so keep an eye out for that next week.