I work on several git repositories though on most not more than 2 people work. Mostly me and my boss. Very often when we work in parallel it happens that "git log" doesn't look so nice because of the merge commits. My boss always complains about that. I really hate that fact because this makes me effectively serialize my work. To prevent these merge commits I must always rebase to the most recent version and go to the other office to make sure that my boss doesn't forget to process the merge requests before committing stuff himself. Even worse he told me that since one week or so he doesn't get email notification for merge request, though I have problems to believe that.

Even more worse he now does himself merge request for peer reviewing, elevating the problem more. (The best part is he thinks I always forget to rebase and update on time...) On several occasions I already tried to explain to him that I do everything the way he suggests but he doesn't believe me because he has more experience with git, at least in non-teamwork-environments.

I work at this place since 3 months, though I actually do teamwork since a few weeks. I really wished we would use svn because with this workflow in git I waste a lot of my time and I get a headache. In particular we have about 40 repos with modules which are in most cases not longer than 3000 LOC. So when I change something intimate in Repo A I might have to change something in Repo B. If I was deciding, I would put all that stuff into one repo, at least the modules which belong to one group of software.

Of course as a new employee you cannot critisize your boss too much or influence him too much. So what is the best way to deal with this problem?

  • maybe look into using branches?
    – stijn
    Jul 2, 2011 at 8:11
  • That's what I (we) do... Ironically this is also one of the things my boss says to me because until yesterday he even didn't believe me that I use branches locally.
    – Joe
    Jul 2, 2011 at 8:14
  • @joe Do you rebase your local/feature branch before merging and deleting?
    – Dysaster
    Jul 2, 2011 at 8:49
  • Then I cannot see how your merge is anything but a fast forward. But of course the others need to do the same, or they end up generating the merge commit.
    – Dysaster
    Jul 2, 2011 at 10:21
  • 2
    It looks like you're stucked with a commit cowboy: years of fighting to be the first to commit (so that he's not stucked doing the merging) encouraged bad habits, so that's going to be difficult to handle until he understands that Git isn't SVN :/
    – wildpeaks
    Jul 4, 2011 at 15:25

3 Answers 3


I assume with this answer that both you and your boss working on the same repositories, so you are having to do real, rather than fast-forward merges.

If you've re-based your work onto the head of your shared repository, you have done as much as you can to keep the history linear.

If he wants a linear history for his own changes, he has to follow the same procedure that he expects you to and rebase his local changes onto the head of the shared repository too.

As it is, I think he is living in the past wanting a linear history, but it is a common desire with people who have been stung too many times by branch handling in older VCS systems. Until you can persuade him otherwise, you have the worst of both worlds, trying to shoehorn a linear workflow into an environment using a DVCS where branching is expected to be the norm.


Your boss sounds like he has decided they way his stuff will work and is telling you to work around that, even though the way he wants it does not line up with how distributed systems naturally flow. (He's also got some issue with micro-management and trust of his employees, but that is not what this question is really about.)

A successful Git branching model
This is a well written and detailed description of a branching model. It allows you to keep things organized and follow the flow of changes. It also speaks to the concept of having a "centralized" origin that everyone can push and pull from instead of you having to merge in from everyone on your team.

The think I like most about that article is its stance on merging.

git merge --no-ff myfeature

Stopping fast forward means that the fact that the branch existed remains intact. Then when you view the log graph

git log --oneline --graph

you will see the branch and merge points and follow the different paths even when multiple people are working in parallel.

  • Unfortunately, it seems that this 'complex' branching is precisely what the original posters boss is trying to avoid. Only once he gets past this aversion to branches will he and the OP be able to use their DVCS to it's full potential. Also, while an excellent article, sometimes I think that pointing people at A successful Git branching model too early can be the worst thing for convincing them to use it - the first image is very off-putting. It would be much less intimidating if that diagram were the last to be see rather than the first.
    – Mark Booth
    Jul 4, 2011 at 15:52

There are several issues here:

  • Using git over svn.

git is better because it's distributed.
git has also become a standard because of issues like this.

  • Relations with your boss.

Clearly you're in a tough spot. In situations like this, 'stop by' or 'hallway' comments will not work. I would recommend you request a formal meeting with him/her about an item that you are very worried about. Use that "very worried about" language in your meeting request but do NOT say what it is about at all. This will get his/her attention!

  • Industry Standards.

With development today it's very important to keep up to date on tools and things change quickly. Unlike when I programmed 30 years ago and tools could be standard for a decade. I would consider using this and other posts in your meeting with your boss.. although this question and answers will probably piss 'em off due to the criticism. So maybe other questions on the same topic.

Final Note:
My last boss used svn and when I tried to talk about how git was better I got the snarky "svn is a perfectly good system, I've been using it for year, it's not like it's fallen by the wayside". The truth came out though when someone - ok it was me - screwed up some code. He then had a hellavu hard time backing it out. Pretty ironic given that this is a super major point of a version control system. So basically svn worked well... until we actually needed key features. I probably should have known this given that he hadn't been to user groups in 3 years, doesn't have a good SO account, etc.
Given your descriptions I would also polish up that resume and make sure you're in touch with the market! Folks that you want to work with will be happy that you're using git !

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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