Git flow work flow in Source Tree

[Chris Dickinson]

Hi all

I've only recently starting using Git and Git Flow in Source Tree, I have a simple question about actual work flow.

I'm working in a branch off the develop branch.

There are changes from a colleague I need to pull.

Is it best to move back to the develop branch and pull the changes without finishing my branch.

Or finish my branch don't push my chnages and then pull the colleagues changes

Or finish and push my branch and then pull the colleagues changes

[Johannes Kilian]

Your situation is not clearly described, a few infos are missing:

Has your colleague used the same branch for development as you did - or was he on his own feature branch? Did he merge back to branch develop - or are his changes still living on his own branch?

The philosophy of gitflow is the following: branch <develop> should always be "buildable" (i.e should be able to be compiled without errors and tests should work). Therefore (and for other reasons) each feature should be developed on its on feature branch <featureX>. After finishing and testing the feature development the <featureX> branch should be merged back to <develop> and software on branch <develop> should be tested. (merging back <featureX> to <develop> should only be done if <develop> stays buildable/ passes all tests  ...)

In your case: if you and your colleague both follow "strict" gitflow principes its quite simple: Your colleagues development was on his own <featureY> branch and he merged back to <develop> and pushed it. You're developing on your <featureX> branch ... In this case it doesn't matter when you perform the pull action: the changes will be merged into branch <develop> (without conflicts) - your branch <featureX> is not touched by this. Depending on whether you need your colleagues changes within your featureX development, you merge <develop> into your branch. If you don't need his changes for your current development, finish development of featureX on your branch and merge <featureX> back to <develop>. Doing so , you can test on <develop> the integration of both features ....

[Chris Dickinson]

Johannes, thanks for the reply - sorry for the confusion.

My colleague and I are working on separate branches. His has finished his <featureY> branch and merged it back into develop. I am still working on my <featureX> branch. I'm not finished working in this branch but wanted to pull his changes so I was working with the up to date code. We are working on different part of the code so I don't think there will be any conflicts.

I'm unsure about the correct workflow:

Do I finish my branch and merge it into develop, then pull the changes.

Or leave my branch switch to develop and pull the changes then switch back to my branch continue working and finish my branch when I'm done and merge it back into develop.

[Seth]

The recommended actions (Johannes did include this in the original answer) would be to leave your branch, switch to develop and pull, then switch back to your branch. If you want, you can merge develop (which will include the other dev's changes) into your feature branch before continuing to work on it. You should never "finish" a feature unless it is actually finished.

[Johannes Kilian]

That's exactly what I tried to say - but my English is not good enough to find such clear and precise words ;-) @Chris: Your branch is finished when it is finished - as Seth said: it should not be considered as finished only for pulling any others changes. Your last sentence "Or leave my branch switch to develop and pull the changes then switch back to my branch continue working and finish my branch when I'm done and merge it back into develop." is exactly the way to go. Generally said: if you want to incorporate other peoples published and pushed features, you switch to branch <develop>, pull the changes, switch back to your feature branch and merge the changes from <develop>. This works the better, the stricter the developers follow pure gitflow (i.e not merging back unfinished features to <develop> and so on)

[Seth]

@Johannes Kilian It wasn't your English that caused Chris to miss it. It was just obscured by the fact that you needed to address multiple situations that the vague question might have been referring to. Since Chris seemed to have missed it, I just repeated it by itself.

[Johannes Kilian]

Your question is not mainly a SourceTree-topic but rather a question on git/git-flow practices