New answers tagged

0

Response from BitBucket: Unfortunately, the feature to link branches with issues to branches is not available on the Bitbucket's built in issue tracker. You can go ahead and file a feature request for this on our public tracker though: https://bitbucket.org/site/master/issues Let us know if you face further issues.


0

Because in Git commits like "make coffee" are considered part of both branches when the feature branch is merged. There's even a command to check that: % git branch --contains @ feature/make-coffee master Also, branches are cheap, local, and ethereal; they can be easily added, removed, renamed, pushed, and deleted from the server. Git follows the ...


2

This is not strictly an answer to you question, but if you want to start a new project, do you really want to copy all the history, branches, etc from the old project? If you just want a working template, say to get the structure of the project as a starting point, but it should have no other ties to the original, then clone the repo but delete the .git ...


0

I think you are doing great by splitting your Visual Studio Solution into several Projects that are creating libraries - as you and @antlersoft said in the comment. This way you can have several other Solutions or even projects that create a standalone binary (like command line exe) referencing these library (Solution Explorer: add reference). The one ...


4

Full disclosure: I am one of the participants in the discussion. The repository's master branch is not it's master branch. The merge into master does not serve any "actual purpose" and that branch is not doing things a branch should do (namely move). You're abusing this branch as a Tag to the latest release. Instead of using a branch, use a Tag. When ...


10

What I'd do in this situation is to mark the failing tests as "ignored" - that way you still have the test so that you know what you need to fix in future, but you're not going to end up with broken builds. If you also tag each test with the issue tracker reference for fixing the issue, that gives you an easy way to tie things together.


0

You only ever, ever push something that actually works. You may have files or changes that you were working on that you don't want to push. You must make sure that your branch that doesn't have these files or changes will work. Your branch may have additional changes made by someone else that may have broken your new code (which the person pushing those ...


2

A good practice is to always do work on branches (see Git Flow for one very common way to do so), and either execute a build against just that branch, or push the branch to a remote (e.g. Bitbucket/GitHub) and have it execute a branch build on your CI server. (Hopefully a build server is part of your development environment.) The goal is to know that the ...


3

In general it does not really matter what you do before you push. It does not really matter to anyone else what your personal workflow is as long as you push according to the standards of your team. In the case you described I would use git stash. In detail: commit b.txt stash other changes test push pop stash


3

Copying copies the working copy, any untracked files, and any local configuration along with the actual repository. Cloning doesn't, but it sets up the origin remote with a tracking branch. Use copying if you want to duplicate your repository so that all remote operations work the same. Use cloning if you want to create a subordinate repository to your ...


3

Your question should involve description of your delivery and development process, and then you could decide which branches you need to maintain. I assume a classical set-up. You have a main development branch - where everything is developed by default, and a release branch, which is what you are preparing to publish as a release to customers. For a ...


4

You should probably read through the PEP yourself. Either Larry Hastings is confused or something was lost in communication. The reasons for moving to git and github over mercurial are not technical, but social. A pull request workflow is perfectly well supported with mercurial, but github is the one with the much wider userbase over bitbucket and ...



Top 50 recent answers are included