We’re rewarding the question askers & reputations are being recalculated! Read more.

New answers tagged

0

NB. I've answered the part of this question I think is answerable: whether X is essential. I ignored the question about why a list of articles don't mention X as probably opinion-based. Isn't keeping the master branch intact essential for collaborating? No. It is often, and perhaps almost always a good idea - but it's very far from essential. If there ...


0

At the peril of attracting downvotes, let me offer an alternate perspective. I don't disagree with the idea that you should only push working code. I am merely offering an explanation. At different stages of development, you have different objectives. During early development, a common rule of thumb is "release early, release often." A good way to get ...


1

To always make sure your main branch (usually master), is always fully functioning. I agree with you. As an external contractor who has to go through rigorous code reviews (3 people!) before my pull request is accepted, it is infuriating to see the company employees check in broken code that they never even once ran (e.g. blatant nullreferences - passes ...


4

Scanning through all the four articles you linked to, it seems they are written from a perspective where the rule to keep "master" intact is assumed to be so basic that it is not worth mentioning. In fact, this rule does not only apply to "master". It applies to every branch which is shared for collaborative work between two or more people of the team, or a ...


3

The problem is that while the code might be identical, the artifact that is produced at E and F is not guaranteed to be 100% binary identical. Some aspect of the build may not be able to reproduced in the same way. This is not a GitFlow problem, it's a problem with your build process. If your build process does not produce the same result with the same ...


1

If the artefacts you build don't contain any information that is tied to the presence/absence of a tag during build time, then there is a way out without rebuilding the artefacts. If you arrange your environment such that the master branch only accepts fast-forward merges, then it can be guaranteed that "commit F" and "commit E" are actually one and the ...


3

If you use gitflow the develop branch can be used in the same way as your demo branch with no merge conflicts. However. Your main problem isnt getting pre release version of the code. This could be done in any number of ways. Your main problem is how to handle the situation if one feature in the demo is not approved for release. You can't change the code, ...


1

Instead of having demo updated with master each time a feature is merged, I think you can create different demo branches from master each time a demo is required. (demo/feature_A, demo/featureB, etc)


1

It is not clear from your description, are your conflicts caused by genuinely different changes in different feature branches which happened to be in same place, or changes in same feature branch which somehow lost their history information. If the latter, you probably are trying to avoid force pushing the demo. So that all the temporary merges are there in ...


7

A few considerations stand out to me. Consider having your major redesign in a branch off of develop rather than in develop. Effectively, what is in develop should represent your next release. If you have an extended test or hardening period, you can create a temporary release branch from develop, test and harden that, and then ensure that is in both master ...


Top 50 recent answers are included