Hot answers tagged

279

You are completely abusing branches! You should have the customisation powered by flexibility in your application, not flexibility in your version control (which, as you have discovered, is not intended/designed for this sort of use). For example, make textfield labels come from a text file, not be hardcoded into your application (this is how ...


83

Having 500 clients is a nice problem, if you had spend the time up front to avoid this problem with branches, you may never have been able to remain trading for long enough to get any clients. Firstly I hope you charge your clients enough on going to cover ALL the costs of maintain their custom versions. I am assuming that clients expect to get new ...


77

In short: Best practice is branch out, merge often and keep always in sync. There are pretty clear conventions about keeping your code in a separate branches from master branch: You are about to make an implementation of major or disruptive change You are about to make some changes that might not be used You want to experiment on something that you are ...


58

the question is should we use branches nowadays? Well about half year ago I was assigned to perform a study to answer that question. Here's the summary, based on references studied (listed below) there's no commonly agreed "best" branching strategy applicable to any project most resources seem to agree that choosing productive strategy depends on the ...


51

To start with, this comment: ... having a branch implies an extra complexity and thus extra work ... is wholly false. I often hear it from people who aren't accustomed to branching, but it's still wrong. If you have many developers accumulating changes locally, their local changes constitute a de-facto branch of the main repository. When they finally ...


41

Unless you are all working out of the same working tree, you are using branches, whether you call them that or not. Every time a developer checks out into his working tree, he creates a separate local branch of development, and every time he checks in he does a merge. For most teams, the question isn't if you use branches, the questions are how many and ...


39

In the future, ask the Joel test questions in your interview. You'd be more likely not to walk into a trainwreck. This is an, ah, how shall we say... really, really bad problem to have. The "interest rate" on this technical debt is going to be very, very high. It might not be recoverable... How integrated with the "core" are these custom changes? Can you ...


35

This depends on the magnitude of the change, but I wouldn't consider it good practice for the differences you described. Generally, you want a Git branch to be something that will be merged in the future or stored read-only for reference. Git branches that co-exist indefinitely mean work for everyone: Changes need to be propagated and merged, conflicts ...


31

One thing people often fail to consider is that a clean architecture doesn't only speed up long term maintenance, it also speeds up development right now. Don't try to insulate your changes from your colleagues until they are "done." Your changes will help them be more productive and less prone to bugs. The most frequent mistake people make when ...


29

The only real defining feature of the master branch is that it's the default for some operations. Also, branch names only have meaning within a specific repository. My master might point to your development, for example. Also, a master branch is not even required, so if there's any confusion about which branch it should be, my advice is usually to leave ...


28

He's mostly referring to the feature branches side of the model. Feature branches were declared an anti-pattern a long time ago when the branches lasted for months and version control systems couldn't merge to save their life. Feature branches that last a week or two have much fewer issues, especially if you're continually merging from develop into the ...


27

One of the philosophies suggested by Linus Torvalds is that creative programming should be like a series of experiments. You have an idea, and follow it. It doesn't always work out, but at least you tried it. You want to encourage developers to try creative ideas, and to do that, it must be cheap to try that experiment, and cheap to recover. This is the ...


22

The claim that "branching is free in git" is a simplification of facts because it isn't "free" per se. Looking under the hood a more correct claim would be to say that branching is redonkulously cheap instead, because branches are basically references to commits. I define "cheapness" here as the less overhead the cheaper. Lets dig in to why Git is so ...


21

Fix the bug in one branch, then cherry-pick that commit into the other branch.


21

I think the answer is given in the subsequent sentence: Keeping stable and dev code separate is precisely what source code control is supposed to let you do. By using #ifdef blocks, you are emulating functionality of a source control system with a C preprocessor. It's the wrong tool for the job. The downside is that you probably either end up ...


19

It probably not that important to explain branching. What is important is that you explain the impact of their non-decision. In this case the impact is if they decide they want the first set of changes down the road it will increase the cost then if you implement the change now. One nice way they will get the message is if you do an estimate for both. If ...


19

Disclaimer: I work for Atlassian DVCS does not discourage Continuous Integration as long as the developer pushes remotely on a regular basis to their own branch and the CI server is setup so that it builds the known active branches. Traditionally there are two problems with DVCS and CI: Uncertainty of integration state - unless the developer has been ...


19

Personally, for your scenario, I wouldn't bother even creating a branch, unless I was working on multiple changes, each of which would need to be accepted by the core developers. Just clone their repository and work in it, then make a pull request. If I were to use a branch then I'd rather use named branches. They were designed for this exact purpose, ...


18

Merging is a funny thing - the less frequently it's done the harder it will be, the harder it is, the more people will be afraid of it, the less frequently they will do it. Solution is either do not allow branches to deviate too much, or not to use branches. If people understand this, you will probably have not much problems with merge, if not - may be ...


17

How much (and what kind of) structure you need depends a lot on what you want to be able to do. Figure out what you can't live without, what you want to have, and what you don't care about. A good example set of decisions might be: Things we can't live without: be able to reconstruct any past release at any time be able to maintain multiple supported ...


17

The real cost of a branch is merging it. Git makes this easier than some other source control systems. See Stack Overflow question How and/or why is merging in Git better than in SVN?.


16

Name the working directories differently. That is, if your project is titled "MY_PROJECT," create a different working directory for each branch. If there is one branch named "dev," then you'd need a directory for trunk and a directory for dev, like this: ~/henginy/projects/MY_PROJECT-trunk ~/henginy/projects/MY_PROJECT-dev


16

A branch is used if you have 2 different versions of repository at the same time. A tag is a way to mark a point in time in your repository. You should add a tag to mark a released version. If you then need to make bug fixes to that release you would create a branch at the tag. You only want to delete branches that have been merged back into the HEAD [or ...


16

This is one of the worst anti-patterns you can hit with any VCS. The correct approach here is to turn the custom code into something driven by configuration, and then each customer can have their own configuration, either hardcoded in a config file, or in a database or some other location. You can enable or disable entire features, customize how responses ...


14

Option A. Just using mainline and tagging for release Pros: You avoid merge hell. Keeping to the mainline encourages some best practices like proper release planning, not introducing a lot of WIP, using branching by abstraction to deal with out-of-band long term work, and using the open closed system and configurable features for dealing with ...


14

The question is awfully general - I can say, with some assurance, that there is ALWAYS some situation where X is a bad idea, no matter how good an idea X is normally. Your co-worker is clinging to a view that was NECESSARY back in the day, when good source control and merge tools did not exist. He essentially doesn't believe that merging can work on a ...


14

developers... accumulate their changes locally... You can see the vicious cycle. It's vicious indeed. Accumulating changes locally is a big red flag indicating that something is severely rotten in dev process. It sort of trashes the whole purpose of having a version control system. As long as you want to stay away from changing the process or other ...


13

I am using this http://visualstudiogallery.msdn.microsoft.com/f3f23845-5b1e-4811-882f-60b7181fa6d6 Updates your title to for example: Development\myproject or Main\myproject or Release\myproject Hope it helps



Only top voted, non community-wiki answers of a minimum length are eligible