Git is a versioning tool that allows developers to track changes, manage version, and work on code (like websites) together. It’s extremely versatile and allows developers to manage history, branch off current work, version the overall project and so much more. It’s one of the most popular tools in any developer’s belt.
When you have more than one developer working on a task at a time, keeping track of the history of changes becomes really important. Keeping track of changes gives us the ability to roll it all back to a previous version of the code if things go awry. To do this we use a tool called Git, an open source version control system designed to handle everything from small to very large web development projects with speed and efficiency. Through this process, clients can benefit from knowing that we not only keep their code safe and secure but also have the ability to make modifications knowing what has changed over the history of a website. We can easily flip between old and new changes with a single command.
From a developers perspective Git is quite versatile and powerful, which is why it’s so popular. Yet to a novice, Git can be a tad intimidating to learn. There are of course many resources to learn how to use Git out there. Instead, we are going to review some good habits to get into (for new and experienced developers a like) that will make projects even easier to manage. Having good Git habits as we work, helps make code changes go more smoothly and safely.
Practice Good Branch Hierarchy
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.
Stash your Changes and Pop Them Back In
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.
Status Check and Check Often
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.
Practice Avoiding Adding all Files in One Go
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.
Write Detailed Commit Messages
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.
Keep your Commits in Check
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.
It’s important to get into good habits, especially early on. Learning to use all the parts of Git will allow you to more quickly get right to programming and you’ll spend less time about worrying.
At White Lion we us these tips (and many more) to keep track of our work so our client’s website code remains intact before and after every change.