Once ready for release, a new versioned branch is created, for each release. All development is done focused on this branch, which is quick and easy to wrap your head around, making for a good developer experience. It’s called “trunk” because the effect of this makes the master branch the most active and useful branch in the whole repo, like a thick tree trunk that supports everything else. The team makes short-lived feature branches, usually not lasting more than a few days, and often committing straight to master. Trunk based development is close to what team programming should be-quick iteration on the master branch, to push out a viable product quickly. This can be very useful for teams to do QA and unit testing to ensure the branch functions properly before being pushed up the chain.
Usually, merging branches is done with pull requests, a feature of hosted Git solutions like Github, where the team requests that master pull from the feature branch, and integrate the changes for everyone. This can be useful for keeping track of individual progress on a given feature or bugfix for example, each branch can implement a feature outlined in an issue in a Kanban service, like Jira, Trello, or Github Issues & Projects. When you start a branch in Git, new commits will be made on that branch, rather than master.
There are two big problems Git branches work to help solve-keeping your internal teams in sync, and maintaining your public release. Getting under control of your Git workflow will, at the very least, save you and your teammates from wasting time googling more Git issues. Luckily, Git provides the ability to make branches, and choose when you want to merge code, which every team should be using to organize their development.
0 kommentar(er)
