0

What are the consequences for software development if we do release a jee project from a feature branch. We are using GIT. Is it a better practice to merge back to the developer / release branch and then build a release from there?

Rene J.
  • 3
  • 1
  • I know this is old, but are you still doing releases from feature branches? If so, any issues you've encountered? – user2966445 Nov 27 '19 at 18:15

2 Answers2

0

Every team has their preferred workflow for git however, one fairly common one that seems to work well for a lot of people is Gitflow.

The general premise is that you have 2 primary branches, master and develop. All feature branches are based off of the develop branch and thus merged back into this branch once they have been peer reviewed and tested. The master branch serves as your production branch. Therefore, the team decides to merge the develop branch into master when they want to deploy a new release of the application.

Jake Henningsgaard
  • 704
  • 1
  • 6
  • 16
  • Thank you Jake. That sounds reasonable. But what are the consequences if in a project there were many releases build from a featurebranch directly for production and then later there are Errors found to be fixed based on this version. do you branch then a hotfix branch from that feature branch? Is the conclusion that this is just an antipattern? Or does it not matter at all? – Rene J. Dec 02 '16 at 15:07
  • I'm not sure I fully understand your question. The hotfix branch is intended for when a bug is found in the production code and changes to that live production code need to be made immediately. The hotfix branch is created from the master branch. You can't rely on the develop branch to make the bug fix because it may not be stable. The hotfix branch needs to be merged in to master and into the develop branch so that it is not reintroduced into the application. – Jake Henningsgaard Dec 02 '16 at 16:20
0

My 2 cents :

If find it easier to maintain the repo if you use a set of central branches (e.g : master and develop).

That way, everyone always use the same references : rebase/merge your new features in develop, rebase/merfe on master for production version.
It is also easier to set up jobs that track someting (e.g : run unit tests on each update to develop, trigger build on each update on master ... )

You can set up a workflow that track moving targets, such as version tags (and write code which checks if 3.2.1 is less than 3.1.2, or something similar), but this is more cumbersome, and gives more opportunity for "bugs", such as :

  • a developper forgets to take into account a new feature : for example, alice succesfully merges her work with bob's, and the push succeeds, but in between, the new target has moved to chloe's work,
  • some blooper when producing 3.2.3 made it so that the last commit on 3.2.2 was not included,
  • ...
LeGEC
  • 46,477
  • 5
  • 57
  • 104