It's good to see another team doing similar things.Īnd optimization I recently made was creating a small CLI tool which helps in creating the release branches and provides for an easy way to essentially cherry-pick the commits in develop (we actually call it release-ready) into master so you don't have to manually go through and use git rebase interactive to remove the commits that are not ready for production.
REBASE FROM MASTER GIT SOFTWARE
Describe the issue in the name, feel free to put details in the What's quite cool is that our teams' software development lifecycle is pretty much exactly this and we kind of organically fell into it. Open a Pull Request against develop (may need to rebase first).When the PR's approved and the code is tested, squash and merge to squash your commits into a single commit.Git checkout -b hotfix/describe-the-problem Working locally # create a hotfix branch based on master, because master is what will be deployed to production
REBASE FROM MASTER GIT PATCH
The most common use case is to patch a bug that's on production when develop contains code that isn't yet ready for release. Use the version number and put the changelog in the description.Ī hotfix is a patch that needs to go directly into master without going through the regular release process. Repeat the steps above against develop (may need to rebase first).We don't want a single commit for the release, we want to maintain the feature commits in the history. When the PR is approved and the staging deploy has been verified by QA, merge using rebase and merge.If there are any issues, fixes should be committed to the release branch. Usually at this point you will want to deploy the release branch to the staging server for final QA. # rebase against master, which we're going to merge into # finalise the change log, local build, etc Working locally # create a release branch from develop If you are unable to squash merge because of conflicts, you need to rebase against develop again: # in your feature branchĪ release takes the changes in develop and applies them to master. This squashes all your commits into a single clean commit.Ie, MQ-330 enable users to order a pizza from the dashboard. When the Pull Request has been approved, merge using squash and merge, adding the ticket number and a brief description:.# if you've already pushed changes and have rebased, your history has changed # push your local changes up to the remote # rebase against develop to pull in any changes that have been made
Git checkout -b feature/XX-123/some-description # create a feature branch that is based off develop Working Locally # checkout develop, fetch the latest changes and pull them from remote into local It will eventually get into master when we make a release. A feature is based off the develop branch and merged back into the develop branch.
0 kommentar(er)
