Search code examples
javaeclipsegitversioningegit

How to implement modular project development in Git using Branching?

I want to use Git for my new java project, which I am going to develop using Java in Eclipse. So I am planning to use Egit addon of eclipse.

Now, there are multiple members working on this project, each assigned different modules. Is it fine to create branches for each individual developer? A single master branch which will be used for merging all the branches into it at the end of a particular release build.

Will this plan work, in the case of Dependencies and Code Conflicts scenarios? like one module's code trying to call the another module's method which is yet to be developed. And 2 different developers have modified the same file and commited in their individual branch.

Solution

  • I have used git and eclipse with a team of over 200 people on a project which lasted 3 years. Let me clarify a few things:

    1. If one of your developers relies on code not yet delivered, eclipse will cite it as an error and will stop helping your developer. Your developer can still use eclipse but it will only be as useful as any text editor like notepad is.
    2. The philosophy of git is to have them working on a private branch in their local workspace so that they do not rely on central server for updates. So in essence they do not use a common branch like in CVS or ClearCase. Updates and commits are made to private repositories and rest of the team is unaffected by this. In essence, your branch is never supposedly in a bad state unless you desire so.

    This is the model we used:

    1. A baseline branch would be published by the build team.
    2. Each developer published a branch/tag (on their own system, tags are lighter as we learned as our project grew over the years) from their private repository based on their own code completion status. This code would be rebased on the current baseline published by the build team.
    3. The developer would then request the build team to merge their code into the main branch for the next baseline.
    4. The build team would get all such published branches in a scheduled manner and merge them and publish the new baseline.
    5. Any merge conflicts would then be handled using one of the following strategies:
      • If the merge conflict was simple the one or both of the two developers would be invited to decide how to merge.
      • If it was complex one the code was dropped from the merge and the developer was informed to do the merge at his end on the new baseline and republish the code for the next baseline.
    6. Any developer relying on code not published by the build team, would pull directly from the target developer with their consent and continue their work.

    Notes: Useful git tools and commands to use:

    1. git gui
    2. gitk
    3. git tag
    4. git rebase

    Note: The build team would have to have some proficiency in handling git to be able to use git properly and to publish clean branches for your team to use.

    Some recommendations: 1. Commit often explaining the purpose of the commited code. 2. Make commits smaller to help make merging easy. 3. Do not alter published branches, it will help reduce a lot of pain (no rebase of published branches, specifically if someone has already fetched them)

    Git is a nice tool and I believe once you have used it is difficult to go back to the traditional tools like clearcase, cvs.