git commit push merge, only I have problems?

Question

git commit push merge, only I have problems?

Navigation

#1 by (4 votes)

1

Good afternoon guys, whenever I'm working with git with more than one developer, using those branch-creating features, committing and doing merge in the master has problems right on the merge? It turns out that other people have already made merge before you, so the conflicts arise, start a step by step of the suffocation with attempts and failures that never solve the merge, after suffering decide to take each of the changes, leave only one branch, delete the others, and stay committing the merges one by one in the master ..

Anyway, I'm a git user, but it's just me who suffers?

SVN only conflicted if the same line was changed, so I had to have the job of choosing which change I wanted, anyway. In Git change a comma in the file of the conflict and I have to suffer to make the merge, using eclipse then neither speak because the folder target that has the class is making a difference, and the ignore does not respect me as I would like.

This is to see if other people have this kind of problem with git and how they did to improve the way they work with git.

git

asked by anonymous 18.01.2016 / 18:21

1 answer

Viewing Query History in Sql Server Management Studio How do I put hover in an image? [closed]

score 4 · Accepted Answer

Good @Jandrei,

As @bigown said, the idea is that with git there are fewer conflicts over SVN.

Maybe the problem is in the workflow you are using. So I'll try to share here what workflow I've been using when I'm working with git.

My first rule: Never work on branch master .

Second rule: If you have more than one developer, nobody pushes directly to the master branch. I always have a second branch ( develop ) where everyone pull requests .

In other words, the developer / programmer works on a new branch inherited from develop :

$ git checkout -b my_new_functionality develop

Once the functionality is complete, the developer pulls the request to the develop branch. The project manager reviews the code and if everything is in compliance, it accepts the PR and makes the merge.

When it is time to release the new version from the develop branch, the manager creates a new branch for this purpose:

$ git checkout -b release-1.2 develop

In this new branch the manager can make some changes like changing the version number, updating the changelog file or README.

At this point the manager can merge (all tests done) from the new branch to master :

$ git checkout master
  $ git merge --no-ff release-1.2
  $ git tag -a v1.2   $ git push origin master

And do the same merge for the branch develop

$ git checkout develop
  $ git merge --no-ff release-1.2
  $ git push origin develop

... And so on.

With this, I avoid conflict problems, or that another dev should commit a blur when editing a file that should not be edited.

It is important that each team member works on a specific solution, thus preventing the other dev from editing the same file. For cases where it is necessary to edit the same file, as long as it is not the same line, git is smart enough to merge automatically.