Home/ Questions/Q 217175
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T18:37:58+00:00

I know the thread which says that rebase is for small changes of teamMates,

  • 0

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-consuming.

I have unsuccessfully tried to make 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 teammate:

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.
    • 0