Remove comments, reformat code to comply with the codings standard and do every other thing you would otherwise notice during the code review Whether it’s the feature branch or the master, all large features need to be merged back using a pull request. Small features, implemented by one or two people, are pushed there not to pollute the main repo. Since Github allows us unlimited forks of private repos, and they do not count to the private repo limit (they are basically free), we use private forks as the RFC branches. We decided to use hyphen-notation for the names.
feature/xyzzy/rfc/xyzzy-2.0 - just to review code, then refactor / fix issues, rebase and merge to feature branch.feature/eglebegle/refactor/xyzzy - using /refactor/ just adds semantics.In addition, you can combine them together:
rfc/feature - this is an unstable branch and will be rebased in the future. fix/eglebegle - just a little change to existing feature (hotfix branches in gitflow). refactor/feature - we’re not adding anything, just refactoring. In this scenario, the main branch shouldn’t have any non-merge commits. Merge them as soon as they are ready to your main feature branch. feature/eglebegle/xyzzy - if your feature is large enough to split into several smaller branches, keep them in this hierarchy. The prefix is important - it designates the branch purpose. feature/eglebegle - you’re working on a feature eglebegle, so this is your stable branch. The CI won’t ever force push into this branch, so committing there is a way of blocking automatic deployments. So no one actually pushes to this branch unless they wish to rollback some changes. env/production (actually just prod) - tests are ran on the master branch, and if they pass the env/production branch is updated and deployed to production. This is known as the develop branch in gitflow. master gets deployed to staging environment continuously. master - every stable feature or fix goes to master. From there, a continuous deployment is set up to publish the application to staging and production environments. We’re focusing our development on branches and using pull requests to merge larger pieces of code into master. Some tool for displaying the history in a graphical way is often useful (gitk or gitx are good choices). Every project, public or private, goes to Github.Īs for the clients - it’s mainly PhpStorm and some command line for more advanced tasks (or for more proficient users). We have tried Bitbucket and Gitlab but with no luck. We used Github from the start and it’s our main and only fronted. It’s loosely based on gitflow, but hasn’t got that much in common. This is the basic workflow for git at Docplanner. We chose this kind of workflow but of course YMMV. Of course, this is generally not a desirable situation, but you may not be able to avoid it, and the resulting conflicts can be a lot easier to resolve if you are generous with integration branches.Git is a very powerful tool and there’s always a lot of ways do achieve same goal. If your feature branches contain major code churns, or if they overlap significantly with regard to the areas of code that is being worked on, you may even want to take this idea further, and have branches that integrate two features before merging them anywhere else, including the global integration branch, i. It's not entirely impossible, but it's certainly a hassle (I have tried). Now, if you had already merged feature branches into one another, you will have a hard time merging them separately into the mainline. However, you still might want to start deploying a subset of the new features to the mainline branch, so you don't block all features because an incompatibility between two of them. This means that they might not, the features might cause conflicts that take a while to resolve. To be a bit more specific on why exactly "separation is good": The purpose of the integration branch is to determine whether new features work not only on their own, but also in combination with other new features.
0 kommentar(er)
