What should be the workflow with a git repository?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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 !