Unable to understand Git branch, merge and rebase

Question

I know the thread which says that rebase is for small changes of teamMates, while merge for large changes.

I keep three Gits of three teamMates in the following directory structure where we all have the same initial code:

project 
      | - I
      | - myTeamMate1
      | - myTeamMate2

The branches are not in the same Git. This means that I cannot use rebase and merge. I have used vimdiff to sync changes between teamMates. However, this is time-consumig.

I have tried to make unsuccessfully the following directory structure where all branches are under one Git:

project
      | - I - myTeamMate1 - myTeamMate2

However, I run clone command for me and for my team mate:

git clone <url>

and I get the error message after running the second clone for my teamMate

fatal: destination path 'dotFiles' already exists and is not an empty directory.

Which directory structure should I use with a team of 3 people, such that I can use rebase and merge -commands?

Answer 1

The fact that they are not inside the same git as you state doesn't limit you in any way. Git is distributed, which means that you can fetch between those repositories, merge, rebase, and so on.

Look at git remote --help to see how you can name your teammates repositories in yours so that you can easily import their changes, rebase onto them or perform merges. There is no need to change your directory structure, yours is perfectly usable.

Answer 2

Just some other thoughts to complete Samuel's answer.

• Unlike SVN, branches and directories are completely unrelated in Git: having 3 branches (one for each member of the team) does not mean 3 directories. That is not what you meant in your question (since your directories are actually 3 roots for 3 Git repositories), but I prefer mention it explicitly just in case ;)

• Git being DVCS, the 3 repositories can be anywhere (not in 3 directories on the same computer). If they are reachable through an UNC path (\\desktop\path\to\repo), they can be designated as remote.

• Git clone does allow you to get references to remotes branches, but does not create tracking local branches allowing you to get the work of your colleagues. The ruby module "remote branches" can help.

• Be wary of rebase as it rewrites the SHA-1 of your branch (since you replay your commits on top of another branch): if your teammates based their merges on your branches, they will have to merge all your commits every time, even those already merged!
  It is best to have 2 branches in this case:

  • a working branch you are using for your development and rebase (to integrate the works of your peers, although even that operation could be done in its own branch)
  • a publishing public branch, on which you only merge your stable work, and which can then be used by other remote repositories as a source for merges.

Answer 3

Truth be told, I started to work on typing a nice, long, detailed response... but I this is already explained much better than I could at http://excess.org/article/2008/07/ogre-git-tutorial/. He covers the use of different branches, remotes, and merging. It's also done in screencast, so take an hour, grab some coffee, and enjoy the lecture.

Specific to your question: you shouldn't use a directory setup. Git doesn't handle branching with directories in the same way that SVN does with branch folders. Branches in git are an entirely different thing. While you may not setup a central repository (I recommend it), you should setup a single master branch that everybody commits their final, clean work to.

One example repository of mine has a screenshot at Wikimedia Commons. In my example, "bartender" submits his code only in tar chunks, so I have to import it myself to manage it. "master" (shown here only as remotes/elf/master) is a public svn repository that I import and base changes off of. "autocracy" is my own baseline for the code, and "private" is where I keep a config file with passwords that I want to manage but never publish. Check the timestamps on private, and you'll notice they don't line up with the branches below. This is because I rebase that branch onto "autocracy" instead of merging.

You'll notice two remote references: elf and bard. These are two remote machines of mine that host the software. I can push and pull my branches to there as I wish. In your case, you'd have remote repositories of your other developers, and they'd modify their own branches. Watching the tutorial will give you a better idea of how it works. Good luck :)