29

I have seen lots of advice about git branching models and the most common opinion seems to be that making changes directly on the master branch is a bad idea.

One of our co-workers is quite happy making changes directly on the master branch, and despite several conversations, they seem not likely to change this.

At this point in time, I can't convince a co-worker that is a bad practice to work directly on master, but I would like to understand the things that will conflict with his way of working, to know when I need to revisit this issue.

Michael Durrant
  • 13,399
linuxunil
  • 1,461

8 Answers8

62

There are several problems when commits are directly pushed to master

  • If you push a work-in-progress state to remote, the master is potentially broken
  • If another developer starts work for a new feature from master, she starts with a potentially broken state. This slows down development
  • Different features/bugfixes are not isolated, so that the complexity of all ongoing development tasks is combined in one branch. This increases the amount of communication necessary between all developers
  • You cannot do pull requests which are very good mechanism for code reviews
  • You cannot squash commits/change git history in general, as other developers might already have pulled the master branch in the meantime
Gernot
  • 736
14

Explain to him that new features need their own development branch that can be deployed to a test environment before it is pushed to production.

Otherwise, you're in a perpetual state of half-completed features. You can't deploy half-completed features to production, so if you're working directly on the master branch, everyone else must wait for you to finish your feature before anyone else's changes can go to production, including bug fixes.

Using independent branches for features means that each new feature can be tested and deployed independently of the others.

Robert Harvey
  • 200,592
3
  • Master should reflect a production branch, a working final version.
  • Working directly in master means that if you create bugs you have no other option for "going back" than to reverse/delete/reset commits, which is not a clean way of working and can cause you to lose the parts of the new code that were OK.
  • Of course, in the very first stages of development perhaps you can begin working directly on master, but after you have something to deliver, you should use development, test or experiment branches to not touch the published, complete, working version.
mcottle
  • 6,152
  • 2
  • 26
  • 27
Tulains Córdova
  • 39,570
  • 13
  • 100
  • 156
3

One of our co-workers is quite happy making changes directly on the master branch, and despite several conversations, they seem not likely to change this.

This leads me to believe there are more issues. Working on master or not is mostly part of a bigger philosophy about how, what and when you release products.

So in tandem with a "you should never work on master", do you have tests of features, do you test each-others work do you review each-others code. Acceptation and integration tests.

If you have none of the above and you're just doing it to "do git", you might as well work on master.

Robert Harvey
  • 200,592
Pieter B
  • 13,310
2

Master should be potentially releasable. Period. There should not be any half finished work in master(unless disabled with a feature flag)

With that said Ive seen some teams complicate their flow.

Not using PR when integrating to master is a mistake since developers will not have the power to choose when integration occurs.

A single development branch brings very little value. Usually it just complicates things. Many feature branches brings much value.

Making branches for each environment(dev, test, prod) is a mistake. This is out of scope for git and should be handled by the release pipeline. The exact same build should be deployed to all environments which is impossible if there are branches for each environment.

If a feature is so big it cannot be done in a day or two all work to a feature branch should be in separate branches and integrated with PR.

Esben Skov Pedersen
  • 5,168
2

Other answers have already mentioned various advantages (isolated features, always shippable code on master, etc) for working NOT on master directly.

For me you seem to have a different issue. Obviously you don't have a development process, which is agreed or used by all of your developers (or your developer in question is totally ignoring the process).

Do you have feature branches, which are merged into master or do you have different releases branches as well or do you use a totally different process?

"Don't use the master branch" is not sufficient.

Simon
  • 1,774
2

First, I want to point out that in git, every pull is quite literally a branching operation, and every push is a merge. The master on a developer's machine is a completely separate branch from the master on a central repo you share, with equal standing from a technical perspective. I will occasionally rename my local version to upstream or something if it suits my purposes better.

I point this out because many organizations think they are using branches more effectively than your colleague, when really they are doing little more than creating an additional name for a branch along the way, that won't be saved in the history anyway. If your colleague is committing features in one atomic commit, it is just as easy to back out as a merge commit of a feature branch. The vast majority of feature branches should be very short-lived and frequently merged anyway.

That being said, the main drawbacks of his style of working are twofold. First, it makes it very difficult to collaborate on an unfinished feature. However, it wouldn't be difficult to create a branch on just those times when collaboration is needed.

Second, it makes review before merge very difficult. On this point, you don't actually need to convince him. You can adopt a tool like github, gerrit, or gitlab, and require pull request code reviews and passed automated tests for all merges. If you're not doing something like this, frankly you are not using git to its full potential, and it's no wonder your colleague doesn't see that potential.

Karl Bielefeldt
  • 148,830
1

There is no "bad practise" around working directly on the branch. But you have to decide what supports your process best:

Question 1: Should your master represent the current release state of your software? Then you should introduce a global development branch and merge the develop at the end of a release development.

Question 2: Do you want to have a code review process? Then you should have "feature branches" that will be merged into master (or develop, if you have one) via pull requests.

Question 3: Is there need to share intermediate code state to other developers that should not be published into production (or test) yet? That is the the case more than one developer develops a feature. Then you should introduce "feature branches".

oopexpert
  • 779