Hi! On Tue, Sep 21, 2010 at 4:42 PM, FernandoBasso <FernandoBasso.br@xxxxxxxxx> wrote: > > I am really a beginner in. Bear with me please. > > Why do we merge, say a testing branch into the master branch ? What is the > use of it ? Ususally, one develops a feature on a separate branch to avoid polluting the "master" branch with non working or fragile commits and prevent other people from working. You always merge a branch into the branch you *are* in. For instance: # Switch to master branch. $ git checkout master # List the available branches. $ git branch * master my-new-feature # Merge the topic branch into master. $ git merge my-new-feature Here what I call a topic branch is what you call a "testing" branch. > > When there is a conflict when merging branches (merging the testing into the > current branch), should I edit the 'current' branch or the 'testing' branch > ? If there is a conflict, in theory it means that *both* sides have change a same location in a tracked file. Usually, it means that you have to take *both* contents and depending on the context write manually the result. For instance, one can fork master to create a topic branch, then changes are made in the topic branch and in master. When you merge back your topic branch you want to integrate your changes but also preserving the changes that have been made to master between the time the topic branch has been created and now. > Should both branches have exactly the same code so that they can be merged > without conflicts ? In general, yes. Please note that git can work around whitespace problems (whitespace versus tab and \n versus \r\n). You may also want to google "git workflow" to get a rough idea about how to manage a project with git and how to do more advanced stuff with topic branches. I hope it helps, -- Thomas Moulard -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html