git-flow

问题 We are trying to adopt the successful Git branching model implemented by git-flow. Now, we are working on at least two release-branches, one for the latest stable release and one for the next (\"preview\") release. What I don\'t understand is why all releases seems to \"linearized\" to the master and tagged there. Why not tag the releases in their release branches? Why the master at all? Or why a develop branch and not use master for it? 回答1: In the git-flow model, your "latest released"

问题 I have two branches: master and dev I want to create a \"feature branch\" from the dev branch. Currently on the branch dev, I do: $ git checkout -b myfeature dev ... (some work) $ git commit -am \"blablabla\" $ git push origin myfeature But, after visualizing my branches, I got: --**master** ------0-----0-----0-----0-----0 ------------------------**dev**----**myfeature** I mean that the branch seems ff merged, and I don\'t understand why... What I\'m doing wrong? Can you explain me please how

问题 Let’s say we have the following situation in Git: A created repository: mkdir GitTest2 cd GitTest2 git init Some modifications in the master take place and get committed. echo \"On Master\" > file git commit -a -m \"Initial commit\" Feature1 branched off master and some work is done: git branch feature1 git checkout feature1 echo \"Feature1\" > featureFile git commit -a -m \"Commit for feature1\" Meanwhile, a bug is discovered in the master-code and a hotfix-branch is established git checkout

问题 When working with git (flow) and having a stage/test environment where the customer are doing their reviews of the things developed what is the best way of handling features that aren\'t approved along with features that are? Consider the scenario that several developers working with different features in a sprint or in a continuous workflow. The features need to be reviewed by the customer and for the features to be able to be reviewed in the stage environment they have to be merged into the