Re: Really beginner on Version Control

On Tue, Sep 21, 2010 at 6:42 PM, FernandoBasso <FernandoBasso.br@gmail.com> wrote:

We usually don't do that, because it goes against recommended git workflows http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html

With Git, you typically merge your stable branch to to your main development branch or you merge some feature branch to master if you consider it to be mature enough to be included in the next release.

You edit files in your working directory to resolve conflicts, after you commit the result to your current branch.

No... There are different merging strategies, and Git is flexible enough to allow you to specify your own merging strategy for some files. The default merging strategy relies on the context to find if there is any conflict. It means that the same file has been edited around the same place (around the same line), then it will generate a conflict.

There is one important thing to keep in mind when it comes to merges. Merge conflict are your friends and not your enemies. In other words, they warn you about changes to some files that can contradict each other, so you need to use your brain to resolve them gracefully. Usually, they do pretty good job at that, but in some rare cases, merge without any merge conflict can produce unworkable code. So, after any non-trivial merge, you should do testing. If testing reveals some problem then you should correct them. Git allows you amend any last commit (including the merge commit) using:

git commit --amend

If two branches are diverged a long time ago, it is very useful to look at history of those branches to find what changes caused the conflict. You can do that using the following command:

gitk --merge

or if you are interested only in one particular file then:

gitk --merge this-file

Dmitry