![]() ![]() (in SourceTree gitflow button > Start a new feature) ![]() We have new tasks to do on the project, change a color, improve a page, add a new function to a module, then we’ll work on a feature that we will call “TASK”: $ git flow feature start TASK The structure of our repo becomes like this: develop Once this is done, if we started with only one branch, that’s a master, then develop will be created. So if you need to change something you can do it here (for those using line commands can find here a list of commands to use to update the config) You can find these configurations in the config file found into the. Tag version: you can leave it empty or, as someone like, put a “v” so that the tag of every version will appear like this: “v1.0.0” This command establishes the names to be used in git flow which are usually like this: On SourceTree click on the Git Flow button How to do itįirst of all, the repository should be prepared for the Git Flow usage.įor those who use SourceTree it’s just enough pressing a button, for all the others. Understood this is also easy to understand why you need a release for features while not for hotfixes because they are released directly in production. A fix can also be simply a documentation updating or reformatting code, even a refactoring that, by definition, does not alter the behavior so it does not add any new feature. To help us, we could keep in mind this triad:įeatures are all those tasks that include addition of functionalities, the usual execution of tasks, etc hot fixes are urgent bug fixes that have to be deployed into production straight away. PATCH a backward compatible bugfix (that’s a fix) MINOR is instead a backward compatible change (that’s a feature or more) MAJOR is a non-backward compatible version with the previous (a break with the past) The version number is build by using the semantic versioning: It’s the release note or changelog (discussed below) that summarise us what’s contained in each version. ![]() form so that we can refer to this version number and be able to “time travel” between a version and the other depending on what each one contains rather than having to remember a specific commit. IntroductionĮvery public or private project/repo should have a tag for every version released in the x.y.z. In Bitbull, we already used to naming the feature branches like this: “feature/fix123” so the visual structure (and those who use SourceTree can better understand here) was: - developĪfter learning Git Flow, I understood why. We will see how to do this using Git Flow which is nothing but a procedure to make it automatic but with some more things and rules to do it correctly.īefore using git flow, we created branches starting from develop called, for instance, “fix123” and the visual structure of the repo was as follows: - develop While the hotfixes are done directly on master (and then aligning develop). Every changes/adding are done on a feature branch generated starting from develop. Typically a repository is divided into two branches, master and develop, where master is the main branch which the code of the production’s version project resides in, while develop is the version with the latest developments that are about to be published and it is usually the active branch in test environment (from now on “staging”). We will not go into the explanation of what a version control system is, but rather we will see how to better manage the development flow with Git, the distributed version control software. The versioning control systems let you keep track of any changes made over time and to cooperate more efficiently within teams of many people, in particular if, as in Bitbull, work remotely. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |