git-flow

Gitflow 实际上就是各个分支的拉取、合并的问题。 代码库存在两个永久性的分支：master和develop，未来所有的开发工作都围绕这两个分支进行派生跟合并。 。 除了master和develop分支。有三类分支的命名规则：feature、release、hotfix。 master ：存储了正式发布的历史。 develop ：作为功能的集成分支。 feature：开发新功能的分支。 hotfix：bug修复分支，用于修复线上运行环境发现的bug。 release：版本发布分支。 feature 分支： 派生于develop 合并于develop 开发一个新功能，从 develop分支 派生一个分支。开发完成之后，合并到 develop分支 ，并且删除 feature分支 。 release 分支： 派生于develop 合并于master、develop develop分支上有了做一次发布的足够功能，就从develop分支上checkout一个发布分支。用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支。发布完成之后将 release分支 合并到 master分支 和 develop分支 并分配一个版本号打好Tag。并且删除 feature分支 。 hotfix 分支： 派生于master 合并于master、develop 线上发布版本有bug的时候，从

I'm following the the workflow described here , as I found many references pointing to this page as a good workflow. As mentioned in the article, "feature" branches are shared between developers, but do not go to the central repository. Let's say a developer "A" starts a new feature branch with git checkout -b newfeature develop . Now let's say that developer "B" needs also to work on this feature. This is my problem. What I did: developer "B" adds developer A's machine as a remote developer "B" runs git branch remoteA/newfeature developer "B" works on this branch, commit his work and pushes

Working with git flow. We have a co-worker who is not familiar with Git that accidentally merged develop into master yesterday. Develop has quite a few features that are launching with our next release, requiring a revert on the merge. This has created a commit which undoes all of the changes. When we merge master back into develop, the revert commit is removing code generated by our features. What is the best way of going about being able to synchronize develop with master's hotfixes, while preserving the new features? -- Edit -- Just to clarify, the revert was a revert . I.E. git revert -m 1

Most of the git workflows I've seen suggest to delete a branch after it's been merged into master. For example, this gitflow suggests the following: # Incorporating a finished feature on develop $ git checkout develop Switched to branch 'develop' $ git merge --no-ff myfeature Updating ea1b82a..05e9557 (Summary of changes) $ git branch -d myfeature Deleted branch myfeature (was 05e9557). $ git push origin develop Why should I delete the branch? I'm also curious what to do when later a bug is discovered that was introduced by the feature - should I create the branch with the same name again, fix

Our software product line requires developing and maintaining multiple software versions concurrently. We are relative Git newbies and recently adopted Git Flow to take advantage of Driessen's branching model . We have a very small software team with few dedicated developers (we all wear many hats) and no "integration guru." Much searching has turned up little specific advice on how to adapt Git and Git Flow to our needs. What has turned up is that Git Flow is not well suited to supporting multiple versions concurrently. One related discussion on SO has answers indicating separate branch names

目标和原则 提高代码质量，及早发现潜在缺陷，降低修改/弥补缺陷的成本 促进团队内部知识共享，提高团队整体水平 评审过程对于评审人员来说，也是一种思路重构的过程，帮助更多的人理解系统 是一个传递知识的手段，可以让其它并不熟悉代码的人知道作者的意图和想法，从而可以在以后轻松维护代码 可以被用来确认自己的设计和实现是一个清楚和简单的 鼓励相互学习对方的长处和优点 高效迅速完成Code Review 流程和规则 采用 Git Flow + Pull Request（PR） 模式来做Code Review。 Git Flow Pull Request（PR） Pull Request 的说明 任务完成才能提交PR 严禁一个PR里面有多个任务，除非它们是紧密关联的 PR提交之后只允许针对Review发现问题再次提交代码，除非有充足的理由，严禁在同一个PR中再次提交其它任务的代码 提交PR时候有一个描述框，内容会自动根据Commit的message合并而成。切记，如果一次提交的内容包含很多Commit，请不要使用自动生成的描述。请用简短但是足够说明问题的语言（理想是控制在3句话之内）来描述： 你改动了什么，解决了什么问题，需要代码审查的人留意那些影响比较大的改动。特别需要留意，如果对基础、公共的组件进行了改动，一定要另起一行特别说明。 PR应该在1~2个工作日内被合并或者被拒绝 发起Pull

Until now my team and I do and did not have anything like an automated delivery process in production. Which may sound surprising to some folks, but it simply did not seem to be essential to our daily work. At least we thought so. I am very sure it is something like a car navigation system or an automatic dishwasher - stuff you would die for if you just started using it. However, as we are planning to launch a not so small project in the next couple of weeks, I want to take care that we are able to not only produce but also deliver updates for it as fast and often as possible. And by often I