Using a development branch in git

[Vagabond]

I was reading over GitHub's recommended workflow here: https://guides.github.com/introduction/flow/index.html.

I was thinking of implementing a develop branch in some of the Git projects I've been working on. Basically, the code in the master branch would remain the same as the current release version. The code in the develop branch would contain all the changes made since the last release.

Then when ready to make a new release the develop branch would be merged into the master branch for the release.

The benefit is the master branch always remains the same code as the current release. So when you clone a project or use it as a submodule, it doesn't default to showing the code past the current in production release. Then when you want to update a submodule, unless you specifically tell it to switch to the develop branch, you would only update the submodule to the most current master (released) branch.

Any thoughts?

-Brett

[Hooman]

Might want to check with Leeor on this. I saw he was using a development branch separate from master in some of his repos.

My thought on that was it was probably more suitable for larger organizations with more interacting developers, and longer more formal release cycles. If it's just one developer making commits to a development branch, and then immediately merging them in to master for a new release, there's no clear gain. The extra branch adds extra overhead to the development process. And in terms of tracking releases, they should be tagged anyway.

I think a relevant question is: In practice, when and for how long will the development branch be different from the master branch?

[Vagabond]

Stop trying to crush my dreams of a dozen people working simultaneously on Outpost related code... 

op2ext went about 3 months before being ready for release. Well it is reasonably ready anyways and the starting code before making changes wasn't even the same as the compiled release code, so we have that going for us. OP2Archive and OP2MapImager seem to go between a couple of weeks and a month at a time with code in the master branch not included in the next release right now.

-Brett

[Hooman]

Hmm, I just read the linked article more carefully. We may be confusing two separate things here.

There is the GitHub Flow model you linked, which uses feature branches to do development. Then there is the master/develop Successful Git Branching Model, which attempts to use a non-default "develop" branch as the base for development.

I assumed you were talking about the second. Interestingly, I just found some comentary on the second article: A Successful Git Branching Model Considered Harmful. I also found yet another article: GitFlow Considered Harmful, though it again seems to be describing the second article with master/develop rather than the "GitHub Flow" article in the first link. Perhaps there is some confusion over the name/model.


In GitHub Flow, the master branch should always be deployable, but that doesn't necessarily mean it's the most recent release. It should be fine to merge in code refactoring, or complete new features that will go into the next version, assuming they've been tested. You don't want to merge in half finished work that will break the build, break existing features, or cause serious security or reliability issues if deployed. Effectively all the experimental work is done on feature branches which are merged in as they are completed. It also opens the possibility for code reviews using pull requests, which might also include automated testing before the merge to master happens.

When I was new to Git and came across the second article, it did sound rather alluring to me. Though now that I've been using Git for a while, it feels like needless complexity that is hard to justify. It's not clear what benefits it actually adds. If the "GitHub Flow" described in the first article is followed correctly, it already protects the master branch from being broken. The question then is what does having an extra "develop" branch really add? My gut feeling is, not much.


Well, you've successfully got me thinking rather deeply on the topic.

[Vagabond]

That was a lot of reading! I hadn't thought that much about high level git use.

Recently, I finally practiced forking repositories, creating a local branch, commiting changes, and then putting in a pull request (PR) for the primary repository to accept the changes. I made 2 pull requests that were accepted by the MonoGame framework (https://github.com/MonoGame/MonoGame). So I was just excited about process. The changes were minor typo fixes, but it was good learning the GitFlow.

I noticed in the process they use a devleopment branch. This made a lot of sense to me for a large library project. If I create an application and link the library project as a submodule, it would default to the last stable release instead of the development/incremental branch. This seems like a better default action then pulling the latest possibly unstable change. Then when I update the submodule, it defaults to only updating to the next stable release. I can change to the develop branch if I want to integrate against the unstable development code.

After reading through the material you linked to, I can see that using the develop branch has downsides though. Particularly in creating more merge committ clutter and reducing the readability of the revisision history. So I guess it would be a tradeoff one way or the other.

I hadn't put any thought into things like hot fixes and release branches, so that was pretty interesting to learn about.

Though I think for the foreseeable future we can just stick to a single master head and then branches for experimental work. Thanks for posting the articles.

-Brett

[Hooman]

Recently, I finally practiced forking repositories, creating a local branch, commiting changes, and then putting in a pull request (PR) for the primary repository to accept the changes. I made 2 pull requests that were accepted by the MonoGame framework (https://github.com/MonoGame/MonoGame). So I was just excited about process. The changes were minor typo fixes, but it was good learning the GitFlow.

It's a lot of fun isn't it 

I had my little learning experience contributing to Leeor's NAS2D project.

For submodules, I believe I read a recommendation somewhere that they should point to tagged versions. That seems to make sense, and would have the same effect. It also leaves master as the usual default for all the other common operations.