Tag Info

Hot answers tagged

50

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


45

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


36

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


32

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

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


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


20

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


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


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

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


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

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


15

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


15

One FPGA developer made a small change and started a build. Another FPGA developer made a commit (after he had been told that his changes did not need to be included in this release and that he should wait to commit). After this commit, the initial build failed. The first FPGA developer then had to revert the other's changes, commit his changes, and spend ...


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


14

Immediately. The key is the question of what the policy for Master is. With git, typically, the branch policy on Master is the buildable stable release. Sometimes, Master is the 'mainline' where branches are made from and merged to prior to merging to a Release branch. These are two different role/policy approaches. It is often a source of errors for ...


13

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


13

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


13

There are mainly two situations where you typically want to start working with branches: when you or your team has to start a new feature which has the slightest chance not to be added to the next release (which may be the first release ever), then start the development in a separate feature branch when you have to provide fixes for severe bugs to the ...


12

I know you're trying to avoid this, but the real insight here is to realize that something is seriously wrong with your codebase: you need to run a full suite of tests that takes a week just to be sure your code is stable! The most advantageous way to fix this problem is to start separating your code base and tests into (independent) sub-units. There are ...


11

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


11

Probably because branch names are only meaningful within one repository. If I'm on the make-coffee team and submit all my changes through a gatekeeper, my master branch might get pulled to the gatekeeper's make-coffee-gui branch, which he will merge with his make-coffee-backend branch, before rebasing to a make-coffee branch that gets merged into the ...


10

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


10

That's not really what branches are for. Branches are supposed to be short to mid-term side paths to your line of development, not long-term parallel versions of the same code. I'd put all the different versions into the same branch, with a subdirectories for the parts that are different between editions, and set up your build process (you have an automated ...


10

My small team switched to a DVCS a year or two ago, and the rest of my company followed suit a couple of months ago. In my experience: People using a centralized VCS still tend to hold off on commits when they are doing a large project. This isn't a problem unique to DVCSes. They'll have change sets that wait several days before doing a commit. The big ...



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