1

Lets think about this scenario: We are a team of 4 developers. We are working in a project that already exists and we need to create new features. For the new feature, no problem. We must to choose who will work on it and after pull updates it will be done smoothly because it will be new files for all developers.

But one of us lets say programmer-1, will only work on some issues inside the code that already exists. So that means he will make changes in his local git and than push to central repository.

Ok, lets say the programmer-1 spent all day and made 100 small changes around 50 files. He added, committed and pushed to the central repository. After that, the programmer-2 will pull all the changes but he will probably have a message like this:

On branch master
You have unmerged paths.
...
...

So the programmer-2 needs to spent a lot of time to pass through all 50 files and choose the programmer-1 changes. Same to programmer-3 and 4.

So, is there a way to set git to accept all changes during the pulling process without asking us to decide what change should we stay with? We will accept the programmer-1 changes every time.

I found this post but it not solved the question properly.

Community
  • 1
  • 1
IgorAlves
  • 5,086
  • 10
  • 52
  • 83
  • 2
    Unless the changes conflict, this is the default behavior. That means you're doing something wrong. Git can always merge changes to different files and often changes on different lines in the same file, but it cannot merge changes to the same lines in the same file. – Dark Falcon Sep 17 '15 at 15:11
  • In the scenario I sit, we will always have conflicts, because the project is already done and one of us will take care of change the code that already exists. So each time the others will pull, we will have conflicts because the code has changed. – IgorAlves Sep 17 '15 at 15:15
  • 4
    As I said, there is no problem with changing code that already exists. **Automatic merging is already handled by GIT if it is able to be merged.** The problem is that somehow you are making changes that cannot be automatically merged, such as two commits changing the same lines of the same files. – Dark Falcon Sep 17 '15 at 15:18
  • 1
    A conflict is two people changing the same lines of code in two different ways, so it's impossible to tell for git which of the two changes to choose. One person changing the code doesn't cause conflicts. – Sven Marnach Sep 17 '15 at 15:25
  • 1
    It looks like you all work in the same branch (master?). You should create separate branches for unrelated pieces of work. – Roman Sep 17 '15 at 17:11

1 Answers1

1

As already stated, Git will actually handle the majority of merge cases if there are no conflicts present. The only time it will not do this is if there are conflicts that it doesn't know how to resolve.

This doesn't seem like a Git problem necessarily, but rather more of a process problem. It seems that a developer is making sweeping changes to the code base, and this should be more clearly communicated to everyone as to what this impacts. Either that, or the scope of those changes needs to be scaled back, since it's having adverse impacts on your work.

However, if you are certain that you will always accept their changes, then you can look into merging their work and accept their work...

git fetch
git merge origin/branch --theirs

...or you can rebase their work against yours (ours in this context):

git fetch
git rebase --ours origin/branch

For more context, check out the documentation around git-checkout.

Makoto
  • 104,088
  • 27
  • 192
  • 230