Git is a very useful tool, allowing us to create branches off of branches and merging them back in. This is a simplified example of the branch hierarchy:

The core of what we work on is usually in the master branch. We can branch off any branch (not just master) to do our work. Sometimes multiple branches at once get branched off and then get merged back in whenever they are reviewed and done.

Whenever we start a project that is larger, we will create a branch off the master that is our feature branch. Then we will branch off the feature branch to piece out tasks. Once the task is done, we create a pull request. This pull request is a request to merge in our changes, and this is when we can easily see all the changes we made. This is also when our work is code reviewed and we either need to make small changes or just merge the changes.

Keeping up with good branch hierarchy helps us keep our tasks organized and avoids either duplicating work unnecessarily or avoiding conflicts.

Sometimes work happens on the wrong branch. Sometimes we need to hold off on a few changes to make a quick fix somewhere else. This is where `git stash` comes in handy. If you are working on the wrong branch, or your quick investigation turns into a task, you can easily stash your changes. Once you’ve stashed them, you can navigate to the correct branch and `git stash pop` all your changes into the correct branch. Easy.

This is also great for making a quick fix on another branch and then coming back to your branch to continue to work. Git stash will remember your work for quite some time. Use stash with care when you are doing this. It’s often easier to commit your changes rather than stashing them if you need to do anything more than a quick fix.

It’s always important to make sure you are working on the correct branch. It’s also always important to make sure you keep track of all your files. `Git status` and `git diff` are two great tools for figuring out what you are working on and where you are. These are especially useful if you are adding or removing files and need to know what is and isn’t ready for committing. Often times a new file won’t automatically be staged for commit. That means a quick status check will let you see what is and is not ready for commit.

Status checking can also help you pinpoint and pick out any files that need removing or need to not be committed.

It’s important to know what you are committing and to commit only the necessary changes. Blindly using `git commit -a` or `git add -A` can lead to files getting missed (if it turns out they weren’t staged for commit) or files you didn’t intend to add getting committed.

It’s good practice to manually add all the files you need the very first time. Once you get into the more powerful tools of git like amending, rebasing, and squashing, then you can use these shortcut tools since you already know what it is you are committing.

git commit -m “Initial commit”
It’s so tempting to just use the inline messaging to write your message for commits, but for large change sets this may mean not giving enough information. If we use `git commit` we get taken to a text editor that will enable us to write out a message. This text editor also has a full list of everything that is being committed. It allows you to more easily write a full message with multiple sentences if needed.
Taking the time to write what changes you made, the problem you solved, or even the task number will help keep track of changes. Then that way, if we need to revert back or roll back a change, we can more easily remove only what needs to be removed or have a better idea of what needs to be fixed.

Think of a commit like a save point. The commit reflects the current, updated work of the task. I don’t necessarily need to have all my work in one commit; I can commit as many times as I need or want to help save my work. That being said, committing, in terms of the branch hierarchy, also means that the task is one step farther ahead in progress with each commit than whatever branch I started from.

For smaller projects where only one dev is working on a task at a time. Keeping commits in check isn’t as necessary. Ideally if your branch is only a commit or two behind, it can be any number ahead with minimal chances of conflicts or issues. But for larger projects, we often have several branches being worked on at once. Those branches may have been created from the root at different points in progress (commits) and time. When we merge those branches back in, sometimes there can be conflicts because the branches didn’t necessarily have the same starting point.

To help resolves such issues we use `git squash` and `git rebase.` These two tools allow us to reorganize our commits say from three commits to one (or however I wish to organize them) with `git squash.` We can then use `git rebase` to make sure my work is not behind any other changes that have already been merged into a parent branch.

These are not the only things we can do with commits. We can also cherry pick changes and commits and amend a previous commit.