When trying out new ideas or workflows, it's often helpful to create a test repository. This lets you experiment freely without impacting any real projects. Working in disposable repositories allows you to become proficient in various Git commands and techniques, all without any risk.
Want to Keep Your Git History Clean? Use Rebase!
If you're looking to maintain a tidy and readable Git history, rebasing is a great tool to incorporate into your workflow. Here's a common scenario: you start by branching off the main branch to work on a feature. You make your changes, and when you're ready, you pull the latest changes from the main branch into your feature branch, test everything, and then open a pull request to merge it all back into main.
To make the most of rebase and keep your Git history streamlined, follow these steps:
1. Create Your Feature Branch
Start by branching off from the latest version of the main branch. This will be your feature branch where all related work takes place.
2. Develop Your Feature
Work on your feature as usual, committing changes to the feature branch.
3. Update the Main Branch
When your feature is ready, switch to the main branch and pull the latest changes. This ensures that your work will be rebased onto the most current version of the codebase.
4. Rebase Your Feature Branch on Main
Now, switch back to your feature branch and run a rebase onto the updated main branch. This step integrates your feature changes on top of the main branch’s latest commits, eliminating extra merge commits and keeping a linear history.
5. Test Thoroughly
After rebasing, test your feature locally to verify that everything works as expected with the latest main branch changes.
6. Open a Pull Request
With your feature branch rebased and tested, you’re ready to open a pull request to merge it into main. Your PR will have a clean, linear commit history that’s easy to review and trace.
Github pull request by default will do pull and merge, but you can change it to pull and rebase.
Main Branch as a Clean, Linear History
With this approach, your main branch history becomes a straightforward, linear progression without merge commits cluttering the log. This results in a cleaner, more readable history, which can make it much easier to track down the specific commit responsible for introducing a bug.
Optional: Squashing Commits for Simplified Rollback
Consider squashing multiple commits into a single one before opening a pull request. This practice consolidates your changes, so your pull request consists of a single, cohesive commit. Not only does this make the commit history cleaner, but it also simplifies the process of reverting a feature if it ends up introducing any bugs.
Here's reddit thread on the subject
Here's a great video on the subject
Working with git using only commandline is hard, and working hard shouln't be your motto. Learn the commandline, but use a GUI to make your life easier.