When you run git rebase -i master, the default editor that is configured with your git will open with a list of commits and some options for how you can edit your commits. It’s more common that I would want to see all the commits I made in my feature branch all at once. The master argument tells git which branch to rebase against.Īnytime I want to squash commits I use git rebase -i master because it gives me all the commits for my feature branch no matter how many commits I make.The -i or -interactive flag let’s us squash commits or perform other edits.I can squash the commits on the feature branch into one commit using this command: git rebase -i master git log # or for prettier git logs: # git log -pretty=format:'%C(red)%d%Creset %C(yellow)%h%Creset %s' -graph -abbrev-commit * (HEAD - > feature) 510a97b change 4 * 65677aa change 3 * 6929064 change 2 * 1914635 change 1 * (origin/master, master) a6334e3 change dog func * 6a31c00 rewrite index.js * 3d6a19c remove index.js * f16edf4 first commit: add index.js I write some code, commit my changes, and now I have some new commits on my feature branch.ĭoing git log will list all the commits. Let’s say I have a master branch with some commits and I create a new branch called feature. And if they did, we were all using merge so 🤷♀️īottom line: whether you’re mandated to use a rebase workflow or not, there are valid justifications for it and against it. For what it’s worth, I don’t think any of the teams I’ve worked with ever rolled back commits on a project. Other teams I worked on in my career usually opted to standardize around a rebase workflow to have the option to rollback commits in case anything bad leaks into master.
SQUASH COMMITS MASTER GIT CODE
The alternative would be triggering multiple granular releases per commit when new code is merged to master. Since each commit on master triggers a new release, all commits in a pull request are squashed into one commit so that a single new release is triggered per pull request. The reason for this had to do with new releases of our npm packages. When I was at IBM working on Carbon Design System, we made it a rule that contributors and maintainers should use rebase and should squash commits for every pull request. Doing this results in a cleaner commit history. In Git, squashing is a way to combine commits - newer commits you choose to squash will meld into older commits. Mark all other commits with the word squash.To squash commits, use git rebase -i master in a feature branch. But a list of commits in git rebase -i master is oldest to newest.A list of commits in git log will sort newest to oldest.First thing is to note that git log and git rebase -i master will list your commits in an opposite order. Using Git to Squash Commits with Confidence Table of Contentsįor me, one big gotcha is that the chronilogical order of your commits matters.
0 kommentar(er)
