313

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 ...


287

I assume you're using git. If so, make use of git rebase -i (the -i means interactive). Make it a daily task (even more frequently, if necessary) to rebase your branch against the develop branch. This brings in the changes incrementally every day (at least) to keep your feature branch up-to-date. If there are conflicts during your daily rebase, you need ...


199

The advantages are mostly the same as for groups of developers. By using an always release-ready master branch, and feature branches for developing new features, you can always release off the master. Find an important bug while working on a feature? Switch branch, fix, release, switch back and continue developing. Or maybe this is a hobby project and you ...


159

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 not ...


150

So that you have a clear and concise git history that clearly and easily documents the changes done and the reasons why. For example a typical 'unsquashed' git log for me might look like the following: 7hgf8978g9... Added new slideshow feature, JIRA # 848394839 85493g2458... Fixed slideshow display issue in ie gh354354gh... wip, done for the week ...


129

This might be a sign of bad software engineering on the company's part. Too many inter dependencies, different issues with overlapping features, attempting to tackle issues in the wrong order etc. can cause the situation you are describing. I suggest regularly merging develop into your branch during development


95

The accepted answers I think are more of a technical "how to use Git better" nature, I think this is more of a team problem than an engineering or tooling problem. If you're encountering a lot of merge conflicts it means that you and someone else on the team are stepping on each others toes. You or they should aim to develop personal space while coding and ...


92

Having 500 clients is a nice problem, if you had spent 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 to cover ALL the costs of maintaining their custom versions. I am assuming that clients expect to get new versions ...


89

If you are using Git, each developer would be pulling from the develop branch into their own feature branch so that they ensure they don't go too far from the current baseline. They can do that daily, so that tasks that take more than a couple days stay in sync and merge issues are resolved while they are still small. When the developer is done with their ...


80

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 ...


64

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 ...


57

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 ...


54

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 ...


44

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 ...


42

I have this problem too sometimes. Git is very flexible. Here's one way you can do it. Your first branch featureA is up for review. Your second branch featureB is in development and depends on the code in the featureA branch. Merge the featureA branch into the featureB branch. If you make changes to the featureA branch then you should merge the featureA ...


42

Long running development Branching for a single person team would be useful for a long-running development feature that otherwise does not fit into your release cycle. You can take a branch for your multi-month spanning change and still be able to push whatever day-to-day bug fixes or changes from your main branch at regular intervals. This has the ...


40

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 ...


39

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 ...


35

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 ...


33

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 ...


33

Create a new branch, because: A brand new branch is less likely to have merge conflicts when you're done and want to merge it into master. Few things are more error-prone than fixing merge conflicts. The feature may have gone through several changes and updates since its original implementation, making the original branch totally obsolete. The only way to ...


32

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 ...


32

Hold on, skip merging For this approach, you do not want to merge your feature_a into feature_b repeatedly. Rebasing has been mentioned in other answers, but only for rebasing things onto master. What you want to do in your case is: Start your feature_b from feature_a, i.e.: git checkout feature_a git checkout -b feature_b Whenever feature_a changes ...


30

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 ...


29

You already have a branch on which your every feature branch depends, and which keeps changing. It's called master. The typical way for a feature branch to stay in sync with master is to stay on top of it. When master changes, you normally git fetch origin master:master && git rebase master in your branch's working directory. You can do the very ...


27

The most important thing about merging is that the longer you wait, the more painful it gets. And the problem grows more than linear. Three times as many conflicts are nine times as much work. There are some strategies: Merge with the development branch whenever it changes, so you are always close to it, and never have a huge number of conflicts. If you ...


26

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 ...


26

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 "cheap"...


24

Because often the person pulling a PR cares about the net effect of the commits "added feature X", not about the "base templates, bugfix function X, add function Y, fixed typos in comments, adjusted data scaling parameters, hashmap performs better than list"... level of detail If you think that your 16 commits are best represented by 2 commits rather than 1 ...


24

I worked in a team where we struggled with the same problem. We found that the less time we had before integrating, the less difficult it became. I know most people teaching continuous integration talk about committing every few minutes - we probably actually committed every hour or so. We also found that just building wasn't enough. We needed a good test ...


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