Git: endless merges. I'm tired of them

Recently I've started working in Git with team of 8 people. We decided that it's a good practice to work separately in each personal branch (someone read about it somewhere). After working in such topology a little while, I've got pissed of how much time takes to get/merge changes from master and push/merge it back. Half of time that I'm spending on issue - takes to merge with someone's changes.

I want to have latest changes from master every 2 hours. But each time I have to spend time to merge them into my branch.

I assume that git is ok and we have chosen wrong workflow. Ho can we avoid frequent merges and always have latest master checked in ?

UPD.

As Neil noticed correctly - some of us are working simultaneosly on one piece of code. That we will get merges in other VCS'es - it's true. but not so often as in git !

For example: I wanted to rename class in the project. This class is using broadly in project. I've made it in my branch. Ok, I've got each time that i'm pulling from master - merges from my teammate. Then I've decided to finally merge it to master. Another one merge. I've made it. Then my teammate pulls and got another merge. So time what spends on merges in team is litterally wasted.

I'm no开发者_Go百科t blaming git. I think there is simply better workflow for this. Now we have decided to refuse using branches and work directly with master hoping that no one will broke our build.

UPD. 2

Also its often happens that I'm getting merge with code that I've never modified. This is odd, as I have to resolve conflicts on code that I've got no idea about. May be there is also some workarounds avoiding these merges?

If you are having a lot of merge conflicts that need to be manually resolved, your problem is the layout of code in your application - it means that several people are working continuously on the same source files. You may need to look at making your code more modular, so that individual developers do not have to all be changing the same files when working on different features. If you don't do this, you will have merge problems with all VCSs.

It seems that multiple people are working on same file and are changing it frequently. This means that your task division or project modularisation is wrong.

Update:

• Personally, I believe branches are better if they are feature specific, rather than person specific. Anyway If you have decided to work on same branch (master). Push soon push often. But make sure every push is stable enough to compile.
• Also maintain another stable branch where you can maintain Stable version of your application.

There are three tools that might help you

• Keep history linear by using rebase. This only moves resolving conflicts around, but the idea is that before pushing to repository, or requesting pull from your repository by maintainer, to use git rebase on top of current version. Note: don't do this on published history. This ensures that the other person doesn't have to resolve conflicts.

  Tongue in cheek: if you are tired of merging, you can git pull --rebase instead ;-) Though this wouldn't help you having to resolve conflicts.

• If you find yourself resolving the same conflict again and again, try enabling git rerere -- it is tool that reuses recorded resolution of conflicted merges.

  You need to set the configuration variable rerere.enabled in order to enable this command.

• If the standard 3-way text merge does not work for you, but your merge conflicts can be resolved programatically, you can set up merge driver for specified files. See description of merge attribute in the gitattributes manpage.

Alternate solution is to shift work around.

Instead of first pulling, resolving merges, then pushing to "central" repository, you can ask maintainer to pull changes from you (git request-pull might help here).

If you are maintainer, you can ask developer to either fix his/her changes so that it would merge cleanly (e.g. by rebasing on top of current version), or asking them to merge. They might know better how to resolve conflicts.

As soon as someone else has pushed changes to the central repository, a merge will happen every time you pull to sync your repository with the central. I assume you mean you are tired of solving conflicts each time.

This problem is not related to git, it has to do with the branching model you are using and what portions of the code you are changing. If you want to get rid of merges completely, it's impossible, if you want to get rid of merge conflicts, start looking at what the conflicts are and how you can work in a more orthogonal way.

It might be the case that someone is changing a file and pushing up with different line endings than other people. This file will always have merge conflicts with people using another line ending, e.g. if you have people developing on both unix and windows.