By the time it gets approved, your pull request has probably become a mess of dozens of commits, with unhelpful messages like whoops and sigh, lint fix. There might even be a revert of some code that needed to be removed from the pull request (and then a revert of the revert!). There may be some commits addressing code review feedback. Then come a few minor commits fixing typos or lint errors. There’s often a handful of incremental commits reflecting the original work the developer did. In my experience, most pull requests look like this by the time they’ve been approved. The best workflow is the one that works for your team.įor demonstration purposes, I’ve created a Git repo with a pull request containing multiple commits. As usual, there’s no one right answer about how to use Git. Long-lived feature branches with many developers committing, or branching again from the feature branch will complicate matters. The advice I give in this post may be less relevant if you don’t use feature branches like this. The team will review the pull request, and once it has been approved, it gets merged, and the feature branch is deleted. When the work is ready for review, they make a pull request back to the parent branch. Most feature branches are short-lived, and there’s only one developer committing work to it. There are exceptions, but in most cases, squashing results in a cleaner Git history that’s easier for the team to read.įor context, our team uses a version of Git Flow, which means team members do their work in a feature branch. As a general rule, when merging a pull request from a feature branch with a messy commit history, you should squash your commits.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |