I work on a large project (C++, C#) in areas that can have a lot of churn. I'm in the habit of getting latest sources multiple times a day. Every now and then this results in an awful back-merge. Usually it results in either having to fix little things, which doesn't take too long, or if I'm lucky they're no conflicts at all (happy dance). One advantage of regularly getting latest sources (even if it results in a back-merge) is that I can always test my code against the latest builds.

I was thinking last night about the time difference between back-merging, say, once a day, or even skipping a day, instead of getting latest regularly. It seems to me like I should just keep getting latest regularly but I've heard strong opinions against doing that. I also have several co-workers that will wait multiple days and only back-merge when they're ready to check in their code and they seem to be doing okay.

Is it okay to back-merge several times a day to keep in sync with latest sources and avoid a large back-merge later?

  • 1
    but I've heard strong opinions against doing that -- We need more than this. What are the justifications for said strong opinions? – Robert Harvey Jul 28 '16 at 16:22
  • 1
    Are large back merges a difficult problem? The descriptions in your question seem to suggest that they are not. As with most things in software development where you're trying to figure out what is the "best" way, you have to weigh the pros and cons of each approach and make an informed decision. – Robert Harvey Jul 28 '16 at 16:24
  • 2
    If your merges are a problem this is a sign that the developers might not be working on sufficiently independent branches – Brad Thomas Jul 28 '16 at 16:48
  • @RobertHarvey The strongest reason against back-merging often was that I might pull in broken code which would make testing my changes harder. Also along the same lines are that I might be bringing in changes that directly affect my current train of thought in code. Even though I will have to refactor and back-merge before I commit my code, it might be better to do that once. I'm leaning towards my "best" way being what I'm currently doing as it seems to be working for me, for now. I'm all for failing fast if it comes to that. – PerryC Jul 29 '16 at 15:01
  • Nobody should be committing broken code to the main/production branch, and if it's not in the main/production branch, I don't think you need it yet. – Robert Harvey Jul 29 '16 at 15:15

You should get the latest at least as often as you push changes. And you should push your changes quiet often if you're in a continuous integration environment.

Personally I don't like to push broken code (others do, and if they clearly label it as such I don't mind). I like to pull, write code, test, pull, test, push. I like to do that many times a day. What is critical is that you don't allow your development and the development of others to diverge for long periods of time.

So yes it's okay. Just be tolerant of others who don't work exactly that way.

|improve this answer|||||
  • It does not seem that others push broken code in this particular situation. They just fix divergences at a different rate. – coredump Jul 29 '16 at 5:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.