![]() ![]() When it comes to squashing and rebasing your commits, the pros significantly outweigh the cons. While this workflow can be dangerous if you don’t have an understanding of what you are doing, after minimal education on the matter, this process is extremely safe. If you really want to have multiple commits for a feature, at least squash down so that each commit builds and passes tests. Another small drawback is that we lose some granularity when we squash our commits. Not all history is lost diehards can still see the original history in the ref log. I propose a clean history is more valuable than one that is hard to understand. Some people feel that history should reflect your true history, the good the bad and the ugly. Since we’re squashing commits and rebasing, we are literally changing the history for the repository. It reduces the risk of losing code when dealing with the conflicts. Since you’ve squashed down to one commit, you only have to deal with those conflicts once, rather than having to work against half-baked code. My favorite outcome of this workflow is that it makes handling conflicts from rebasing simple. Have you ever seen a git log graph that looks like this?īecause each commit contains all the code for a feature or bug fix, you can easily see the whole unit of work in a commit, and you don’t have to worry about checking out the correct commit from a branch. Git bisect becomes almost completely ineffective if there are broken commits on the master branch if you jump to a commit that isn’t clean, it’s difficult or impossible to tell if it introduced the bug. You can use git bisect when trying to find the source of a bug. ![]() This simple fact makes debugging an issue much easier. If you follow this process it guarantees that ALL commits in master build and pass tests. Git push origin master Why should you adopt this workflow? Handle any conflicts and make sure your code builds and all tests pass. If you have previously pushed your code to a remote branch, you will need to force push. In that case grab the SHA from the last commit that your branch branches from. Sometimes you will have large enough number of commits that counting can become troublesome. Which will show a graph of your commit log history and may be easier to visualize your commits. Git log -graph -decorate -pretty=oneline -abbrev-commit You can simply git log and count your commits, or ![]() Get the number of commits from the start of your branch. ![]() Make sure the final commit is buildable and all tests pass. Make changes as needed with as many commits that you need to. It’s simple – before you merge a feature branch back into your main branch (often master or develop), your feature branch should be squashed down to a single buildable commit, and then rebased from the up-to-date main branch. After working with a wide variety of team sizes and dynamics, I’ve found that the squash and rebase workflow helps make the collaboration process more efficient and a hell of a lot less painful. Like any tool, if misused, it can also cause some serious headaches. Using git for version control allows for powerful collaboration in tech teams. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |