3/19/2023 0 Comments Sourcetree pull requestGit-flow determines your context simply from the branch you currently have checked out, so it’s fine to jump around if you like. If at any time you want to switch branches, either to another feature branch or to somewhere else, just use the normal mechanisms in SourceTree to do that, such as double-clicking a log entry or a branch in the sidebar. If you want, you can push the feature branch to your remote while you work on it (your team can decide on whether that’s normal practice or not). You commit your feature implementations to this branch. In this case, a new feature branch called ‘feature/my-new-feature’ will be created (I used the default prefix when I initialised this repository). The first thing to note is the ‘Preview’ window, which is present on all of the action dialogs and shows you what will actually happen when you confirm the dialog. This ‘Start Feature’ action will be the default action when you click the Git-flow button if you are currently on the dev branch. You can commit trivial changes directly to the development branch (‘develop’) if you like, but any time you start on something non-trivial you should explicitly start a new feature. Next up, we’ll concentrate on the actions we can perform with Git-flow and SourceTree. For more details please see the Help section included in SourceTree. You’ll probably just want to use the defaults in the initialisation window so that’s not covered here. If you haven’t used git-flow already on this repository, the first thing SourceTree will do is initialise your repository to use it. You can always get to all the other git-flow actions via this button as well, but most of the time the default option will be the action you’ll want SourceTree to perform. If you’re already on a feature branch, it will offer to finish your current feature and merge it back into the development branch, and so on. If you’re on the development branch, it will default to starting a new feature. So if you haven’t set up git-flow on this repo yet, it’ll help you do that by default. There’s a handy new addition to the toolbar in SourceTree 1.5 (keyboard shortcut Cmd-Alt-F):īased on the current state of the repository, the Git-flow button will bring up a dialog with the most likely action you’d want to perform next. SourceTree helps you utilise these branches via git-flow actions which we will describe below. Once you’ve made your changes, the hotfix branch is then merged back into both the master branch (to update the released version) and the development branch (to make sure the fixes go into the next release too) If you need to patch the latest release without picking up new features from the development branch, you can create a hotfix branch from the latest deployed code in master. Hotfix branches (usually prefixed with ‘hotfix/’).You can commit to it during your preparation for a release, and when it’s ready to be deployed, you merge it into both the development branch and the master branch (to indicate that the release has been deployed). When you’re about to package a new release, you create a release branch from the development branch. Release branches (usually prefixed with ‘release/’).When finished, you’ll merge this branch back into the development branch to queue it for the next release. When you start work on anything non-trivial, you create a feature branch. Feature branches (usually prefixed with ‘feature/’).Only updated by merging other branches into it. This branch represents the latest released / deployed codebase. Production branch (usually called ‘master’).This is your main development branch where all the changes destined for the next release are placed, either by directly committing small changes or by merging other branches (e.g. Development branch (usually called ‘develop’).The general idea of git-flow is to use the following branch structure in your repository: SourceTree 1.5 now integrates with git-flow and presents it to you in a friendly and intuitive way. Get new developers up to speed more quickly.Move between projects more easily with familiar branch structures.Adopting a standardised approach has many advantages: Using many separate branches in Git gives you lots of flexibility, but it can get complex. The idea was to standardise branching and merging when developing features, handling releases and managing hot fixes, in order to be consistent and gain the advantages of git’s ‘branchy’ development model. In early 2010, Vincent Driessen wrote an article called “A successful Git branching model” which recommended an approach called git-flow to use git branches in your development cycle. Note: for brevity this article refers to Git and git-flow, but SourceTree supports exactly the same concepts in Mercurial via Hg Flow too. Smart branching with SourceTree and Git-flow By Steve on August 1, 2012
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |