What are we doing wrong with git?

There are 3 of us working on a Django project using git.

I have more experience than the other 2, so all the changes come by me before they get into "master".

We are all running windows, and we aren't where disk based shares will work so we all have separate "origin" repos in our individual accounts on a linux box. These act as a way for us to share our changes with each other and as an "offsite" backup of our repositories.

One of the other 2 people creates a branch, lets call it BugA, and they make fixes. Then they push it from their work machine to a linux 开发者_如何学运维machine we all have access to so that I can review the changes and merge them into the "master" on my account (which is considered THE copy of the code that goes to production).

Once they finish BugA, they will begin BugB with a new branch. As I'm reviewing their work, I find some problems (excess code, comments missing, etc....) So I make changes to their code, test it and commit it to master.

Then they send me the fixes for BugB and I get all kinds of conflicts with their changes. Those conflicts are on the lines of the code that I changed in their commit.

When they try to merge with me, they report conflicts on their end too.

While writing this, I think I'm beginning to understand what might be wrong. I'm merging their code into my master, making edits and commiting. I really need to be making the changes into my their branch in my repo, pushing that back for them to merge with, and then merging them into my master.

What I'm not sure of, is what to do about it. Once they merge with their branch from my repo, then they have to merge with my master? 2 merges instead of 1?

Because of the way we have an externally hosted repo on the linux box that means twice the pushes, twice the merges etc....

Is that really how it should be working?

As I understand your question, you have three remote repos ("origins") where everything is going on:

• your repo (that with the production code) repo_mark
• repo of user1 repo_user1
• repo of user2 repo_user2

And the scenario is the following:

• user1 creates a bug fix branch (BugA) and does some fixes
• then, he pushes the changes to repo_user1 (his origin) with git push origin BugA:BugA
• then, you fetch the changes doing a git fetch repo_user1 and merge the branch BugA (including some changes that you had to do) into master of your origin (which is considered to be the global master repo)

To make things consistent, you don't have to work on three repos; use just one. The guideline would be that only you are allowed to push to repo_mark/master while your colleagues may push to Bugfix branches in that repo.

So, user1 doesn't push the BugA branch to his origin (that doesn't exist) but to repo_mark/BugA.

Once you put the changes of BugA into repo_mark/master (which is considered as THE repo), you tell your two colleagues to update their working copies (i.e. do a git fetch origin where origin is repo_mark) followed by a

git checkout master
git rebase origin/master

Now, all of you three share the same master branch. And – you mentioned backup in your question – every user that fetched has a complete backup of your repo_mark now.

This would be the right time to delete BugA in repo_mark by telling git to

git push origin :BugA

and for user1 to delete his local BugA branch.

If the work for BugB started in the meanwhile, the user working on BugB does a

git checkout BugB
git rebase master

after you told him to update. Some conflicts might arise, but don't have to.

If the conflicts were resolved, he could continue working on BugB and finally pushes the work to repo_mark/BugB.

Edit: The answers to git -- locking master branch for some users? will show you how to lock master for your colleagues.

Edit 2: Of course, you could keept the other two repos for your colleagues to backup their work there: they push to these repos until their work is ready to be passed to you and then push to repo_mark. But in that case, they would be responsible of keeping their repo in sync with yours and you should be off the hook in that case.

The only way I can see the conflicts happening is if by "making changes to their code" you mean actually modifying their commits, i.e. creating commits with a new SHA1 and checking those in instead. If you're trying to keep your history "clean" (overrated in my opinion), there's no away around those conflicts. However, if reducing the work of merging is more important, then instead of changing their commits, you want to create a new commit on top of it that contains your fixes.

If this isn't how you've been modifying their commits, that means there's something else in your workflow I'm missing. Let me know and I'll see what else I can come up with.