2

We are a bunch of developers, without leader and I think we have a problem with project management at a fundamental level. When we got tasks (related to story or error), we have two options:

  • Create one volatile branch for each issue:
    1. Pull master
    2. make changes
    3. push to remote new branch
    4. wait for somebody to merge/cherry-pick it to master.

The disadvantage is that a lot of branches arise, the merging of which requires more work than the master master.

or

  • Use one permanent dev branch per user:
    1. Merge master to my dev branch
    2. make changes
    3. push it to remote my dev
    4. wait for somebody to merge my dev with master.

The disadvantage is that there are many commits containing only merge master to dev, and merge dev to master.

The real problems shows when we simultaneously edit the same files - sometimes git do not notice that the changes are contradictory and will cause unpredictable errors.

We often change the same files, change names, move, delete, create new ones, at the same time, because we have to do a lot of refactoring old c++ code.

Which of this two options are better? Which give us nice git log for efficient catching errors in parallel editions and easily blame each other?

How to avoid duplicating cherries and excess merge commits, and at the same time ensure that the private dev branches was always up-to-date?

1
  • Thanks. It's good to use the right tools for the right purposes. Dec 6 '17 at 23:58
5

Use one permanent dev branch per user

Can it happen, that whoever manages your project comes in and decides that another feature is more important, or that you need to fix a bug first? Then one branch per developer is doomed to fail. Or you complete two features and suddenly the feature you completed first is cancelled?

You need one branch per feature. Because priorities change.

1
  • Thank you. We will use one branch for each feature, and one branch per coder for fixing small bugs. So we can merge bugfixes to master every day, and at end of sprint we'll get new feature from dedicated branch. Dec 6 '17 at 23:02
-1

It sounds like technical discipline challenges more than management ones.

Mo' branches, mo' problems!

  • Keep the repository as simple as possible
    • more branches = greater complexity
    • Sharing reveals conflicts sooner
  • Make small, incremental changes
  • Commit often
    • No less than every day
    • Ideally many times daily
  • Pull before any push
4
  • Branches do not make complexity, all they do it prevent it being hidden.
    – mattnz
    Dec 7 '17 at 1:43
  • Each new branch adds a level of complexity with more merges between branches. What if two features need the same shared code that other features do not? (Baseless merge? Additional branch? Code duplication?!?!?) Frequent commits into a single branch reveals conflicts sooner, reduces the magnitude of conflicts, and promotes better technical practices. Dec 7 '17 at 3:11
  • Thank you - You have provide a perfect example of the complexity Merges expose that exists anyway but it hidden by refusing to use the feature branch model. If two feature need the same shared code you have three issues - the functionality the shared code provides is a separate deliverable. The features that use it are then added to that functionality. Ignoring the complexity does not mean it does not exist.
    – mattnz
    Dec 7 '17 at 5:23
  • The longer any branch exists, especially without merge, the more divergent the code bases and the higher the risk. Dec 7 '17 at 20:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.