git merge direction

Hi Experts,
I noticed that when I tried to merge my master branch to my report branch to "speed up merging later on", that I actually made my life more difficult.  That I was pulling changes in other files that I had removed in my branch, that this new branch explicitly removed for its purpose.

So it's silly, but I'd like a confirmation from someone that there should never really be a need to pull the master branch into another branch really- if your workflow is only to ever release from the master branch....

To be more precise, I should be able to create as many branches I want and only ever merge them into the master branch when they're ready- no need to merge at any other time.

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

My experience is mostly with Team Foundation Server, but all source control that allows branching and merging rely on the same basic concepts.

Scott Guthrie posted a good web cast a while back explaining different branching and merging strategies. His main point was "do what works best for your coding." He recommends that you merge every so often to make sure your code isn't too out of sync, but elaborates by saying that is mainly for parallel branching strategies.

In short, if you only have one work branch that you are developing on at any given time, it is not an issue to do one merge shortly before deployment.
trinitrotolueneDirector - Software EngineeringCommented:
>>>>I tried to merge my master branch to my report branch to "speed up merging later on", that I actually made my life more difficult
yes this should never be done.

I would suggest merging your changes periodically with the main branch. But then this depends on how much the files in your branch depend on the main branch's changes.
Rather than keep pulling in from the main branch just merge your changes and create a new branch altogether
The main point of having a main branch is to keep active development completely separate from the production version until it is ready to move out. It allows you to make bug fixes in production while maintaining a development cycle. If you merge to the main branch prematurely it completely defeats the purpose of having a branch. While developing you always want to merge from main to development branch to prevent this.

With multiple development branches, if they exist, you want to periodically merge those together to make sure they don't get too far out of sync.
Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

@strickdd: I do not agree but I may be wrong.  Or we mean the same but I did not find it clear from your description.  I may be wrong as my point of view reflects my experience with using the CVS.  The Git cheep branching may lead to other approaches.  Because of that I would also like to hear your opinion.

The main branch should contain all official unmodified releases, but also all development releases that add new features that lead to the next official release.

When a bug is found in some release or when the decision is made to backport some feature from the future version, the fix or the backported feature should be added to another branch that is dedicated to modifications.  The reason is that the modifications can be done even after the newer version was released, therefore the timelines of the modified version (i.e. containing the official modifications) and the timeline of the main branch must be separated.

In other words, a developer should always work in his/her private branch created or from the trunk or from another branch.  After being confident that the modification works, it should be merged back to the original branch shared by more developers.  

Porting or backporting of some features means something else than merging a branch with the feature.  The reason is that porting/backporting between say main branch (trunk) and the modification branch (the shared one that contains official fixes) often requires manual intervention and adopting of the feature to the possibly slightly different approach to the implementation.

The shared branches (the trunk and the fix branches) may contain both the official releases / official modification respectively, and development versions in between them.  The official and development releases should only be tagged differently.  My reasoning is that also the development versions should be of the similar "design" quality as the official ones.  The only difference between them should be made by decisions other than technical -- say "There is enough of new features to make it the official release".
threadyAuthor Commented:
Let me make a really simple example to see that we're all on the same page:

I have a branch called SomeNewFunctionality and want to merge it into the main branch.  It's not 100% perfect yet, so I'll create another branch of the master branch, call it masterCOPY.  Then I'll go in masterCOPY and merge SomeNewFunctionality into it (which is safe to do, because no one is using masterCOPY).  Now I can rename my masterCOPY to SomeNewFunctionality and I've essentially given it all the changes and brought it as close as possible to the master branch, making my life of merging easier before "going live" with it.

Sound good?
That should work fine.
evilrixSenior Software Engineer (Avast)Commented:
Hey Mike.

Why do you want to merge changes back to master (and vice versa) before they are complete (and tested)? In general, it is better to keep all changes away from master until they are production ready.

Merging branches in both directions is also going to cause you pain. There is no super nice way of creating a branch, making changes to that branch and then merging master to it again. This is really a recipe for disaster (at best, a nasty set of merge conflicts to deal with).

It is better to wait until your branch is production ready. At that point you can then make the following choice:

If your branch and the master haven't diverged (ie, you branch is a direct descendent of the current tip of the master branch) then merging is the way to go because all that needs to happen is the master needs to be fast-forwarded (there is no actual merging to be done).

If your branch and master have diverged a rebase is probably a better bet (but you can try both since all you need to is hard reset master to get it back to the state it was before you tried the merge). When you merge all your changes are applied on to of the ones made in master, when you rebase the changes to both branches are played back in chronological order (ie, your changes and the ones in master will be interlaced). This often (but not always) ends up with less conflicts. It also leaves you with a cleaner history.

Generally, if everyone just works in their own branch(es) things become a lot simpler to manage.

>> I would suggest merging your changes periodically with the main branch.

I would strongly suggest your don't do this. Not only is a a bad idea to taint master with untested code it is also completely unnecessary with Git. Git is not SVN -- branching and merging are (generally) trivial and the amount of time and changes does not make this any less true.

There is a danger of those who do not use nor understand Git basing their recommendations on experience with other SCMs. Git is quite different to most other SCMs and what is best practice for them is not necessarily best practice for Git (and vice versa).

The model normally used when developing with Git is to create release branches from master. Create branches from release for features and development. Merge these back to the release branch when they are done and merge the release branch back to master one the release is ready. Unlike SVN, Git makes this branching model simple.

Or, put another way -- this is generally the best practice for Git branching

>> Sound good?
Why bother? Just merge back into master once your work the branch is complete and tested. If you have specific changes in master than you want in the branch just cherry-pick them into the development branch or (if the work was done in another branch first as would be the better case) just merge the change in from the other development/feature branch.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
evilrixSenior Software Engineer (Avast)Commented:
>> That should work fine.
But it isn't the way to go -- you are just making more work for yourself.
threadyAuthor Commented:
I guess it's because my "SomeNewFunctionality" branch is getting large and there's going to be lots of merging. So I'm inclined to not want to have to do all that merging in the end all at once.  If I can do a little now, it's better than doing it when I'm being rushed to get an update out later....

Note that I have not merged anything into the master branch yet in doing what I'm doing....

Still a bad idea in this case?
evilrixSenior Software Engineer (Avast)Commented:
>> I'm inclined to not want to have to do all that merging in the end
Heh, well as I said, if master and branch are not diverged it's a trivial matter.

Have you considered branching from your branch to create incremental feature branches? You can then merge these back into master in a more granular way.

>> Still a bad idea in this case?
I would avoid it. If you break master no one will thank you ;)
threadyAuthor Commented:
This is one mega-feature being added.  It is atomic.  But I get the drift!  Thanks evilrix and everyone!
threadyAuthor Commented:
thanks again
Thanks all for the nice discussion. ÿ If interested, I have posted the related question http:Q_27387026.html.
threadyAuthor Commented:
apologies to trinitrotoluene- I would have given you points as well- I just missed you!  Sorry about that!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.