Tag Info

Hot answers tagged

56

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


52

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


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


38

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


33

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


25

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


25

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


23

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


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


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


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


15

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


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

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


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

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

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


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


12

One of the branching philosophies (section Developing Branching Strategy and Codeline Policy in Advanced SCM Branching Strategies - also read Perforce Best practices, its a pdf but goes into some other details) is that you branch on incompatabile policy. A codeline policy specifies the fair use and permissible check-ins for the codeline, and is ...


11

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