Gitflow + Forking workflow (on Stash)?

Question

Is it possible to use Gitflow on top of a forking mindset? If so, how would you do things like create a local feature branch, push it to your origin and then pull request it? Would you pull request a branch to make it available to others? I'm especially interested in how this works with Atlassian Stash.

Thanks!

Answer 1

Stash developer here.

I think what Chris was getting at with his question is that technically forking, or not, should have no impact on gitflow. The feature/bugfix branches can either live in the main repository or on a fork. It doesn't, however, make sense for the release branches to really live in forks because it's not something you generally want to have diverging copies of (although you may well raise a bugfix pull request from a fork into a release branch).

Generally with features and bugfixes, if you're using either forking or just using branches in a single repository, then creating a pull request to the upstream repository is the best means of signalling your intent to merge into the dev/master branches, which then becomes an appropriate place for code review and conversation about the changes.

When you say 'collaborate' on a branch do you mean have multiple people working at the same time, or just code reviews. Assuming the former then there's nothing stopping you from having a personal fork where you have granted permissions to someone else and you either both push to the same branch, or you create pull requests between your forks, and then eventually back to the upstream repository. Whatever you like.

Specifically regarding Stash, there are some answers here which might give you an idea of how Stash interacts with GitFlow:

https://answers.atlassian.com/questions/220237/stash-branching-model-vs-git-flow

https://answers.atlassian.com/questions/165443/git-flow-with-stash

Just some food for thought on forking vs branches - the Stash team mostly uses a single repository with bugfix/feature branches. There are two reasons for this.

1. It makes having branch builds in Bamboo (or your CI of choice) much easier, at least for now. Bamboo can poll that repository, look for branches matching a regex and create a build for each one without any manual intervention. It gets a little more complicated with forks.

2. Visibility within the team - you can automatically see what people are working on without having to go to Stash or track each personal fork.

Forking is perfect when you don't have trust between two parties or need some form of enforced isolation, like open source. However, if you're in an organisation where you "trust" everyone on your team I would argue that having a single repository makes things much easier/streamlined. Just my 2c.

I hope that helps?

Answer 2

I think in terms of using git-flow with a fork one of the questions that's bound to come up is the usual: if tracking upstream (which is desirable), where do the upstream changes go? Indeed, that was the first thing I thought of when I stumbled across this thread a few moments ago.

The thing is, when you eventually "git flow feature finish feature/whatever" it will end up merging back into your fork develop branch. That's all good. But then eventually you will get to "git flow release start X.X.X" and "git flow release finish X.X.X" and that will result in a merge into your fork master. If you have been blindly pulling upstream changes directly into master, then your fork may begin to diverge from your intended goals for maintaining the fork in the first place. What you really want to do, I think, is cherry pick from upstream.

In which case, the normal method of tracking upstream applies: create an "upstream" branch and set it to track upstream. No, git-flow won't do anything with that "upstream" branch, but then just because you are using git-flow it doesn't mean you can't create additional branches. Or use other features of git in general that git-flow doesn't necessarily do anything special with.