People want to avoid merge commits because it makes the log prettier. Seriously. It looks like the centralized logs they grew up with, and locally they can do all their development in a single branch. There are no benefits aside from those aesthetics, and several drawbacks in addition to those you mentioned, like making it conflict-prone to pull directly ...
In two words: git bisect
A linear history allows you to pinpoint the actual source of a bug.
An example. This is our initial code:
Branch 1 does some refactoring such that arg is no longer valid:
Branch 2 has a new feature that needs to use arg:
There is nothing too difficult about SVN merging... anymore... if you follow the right philosophy
What I see in most other answers seems to come from people who haven't used SVN in a while. As someone accurately mentions: "it wasn't fixed early enough to dispel the myth".
From my current experience of using SVN 1.6 to 1.8 on a legacy project I inherited ...
You should commit often.
But @durron597! I'm a beginner programmer! I don't trust my commits!
This is why you are committing on a separate branch!
You can even have many branches that you're committing to for your own use, for different fits and starts and experiments and whatnot.
Don't worry about big fancy commit messages. The only commit messages that ...
In short, because merging is often another place for something to go wrong, and it only needs to go wrong once to make people very afraid of dealing with it again (once bitten twice shy, if you will).
So, let's say we're working on an new Account Management Screen, and it turns out there is a bug discovered in the New Account workflow. OK, we take two ...
First of all, the use of feature branches (to isolate the work done on a feature) and CI (to find integration problems as soon as they are committed) are slightly at odds.
In my opinion, running CI on feature branches is a waste of time. As feature branches come and go frequently, the CI tooling would have to be reconfigured over and over again. And that ...
I know it's not exactly the same, but could you use a workflow where you tag the feature branches before ‘closing’ them?
git merge feature-wxyz -m "Merge message"
git tag closed-feature-wxyz feature-wxyz
git branch -d feature-wxyz
Of course, you could also annotate the tag (git tag -a closed-feature-wxyz -m "Description of closed ...
A no less effort but more permanent fix would be to split feature X and Y each into their own repositories. Then the master would just reference the other repositories as libraries (best practice for this is to use submodules).
This way you do not need to manually add the new development to feature X as you are using it straight from its own repository.
If you just want to merge a branch while still keeping a record of it's existence, you could always tell git not to fast-forward the merge using git merge --no-ff this will create a new commit with two parents, and a commit message along the lines of "Merged [branch_name] into master"
Since git allows you to check out any commit and make a branch from it, ...
Rebasing provides a moving branch point which simplifies the process of pushing changes back to the baseline. This allows you to treat an long running branch as if it were a local change. Without rebasing, branches accumulate changes from the baseline which will be included in the changes being merged back to baseline.
Merging leaves your baseline at the ...
The main reason not to force a push is that it forces everyone else to do rebases or force pulls, and any outstanding branches will not merge cleanly. Also, when beginners don't really understand how to use DVCS yet, a force push is usually a sign that you forgot a step, like doing a pull or merge first, and you can accidentally lose history or even ...
We have to distinguish two kinds of versions:
VCS like Git store the development history of the software.
These versions have nothing to do with different editions or variants of the software.
Trying to conflate both is a recipe for pain.
Especially with Git, a commit represents a specific state of the software and not just a set of changes. So if you ...
I would advise you to stay with SVN for the MS Office documents for two reasons:
It is already there and it is (in my opinion) better for keeping
Office documents (look here). Has much more third party tools for doing this.
The lock, though can be achieved in Git, is not "the Git kind of way
of doing things". If you need these features, stick with the tool
I think the workflow at its core is fine and basically follows the ideas presented here: A successful Git branching model. However, I think the reason it breaks down for you is because you are essentially "off by one" in the merging and testing process:
Feature branches should be based off of the development branch instead of the stable/master branch. Long-...
In response to 1)
Any way that works is a good way. However: the whole premise of Continuous Integration is to integrate continuously. The idea is to catch integration bugs not only as early as possible, but within the development feedback cycle - i.e. while all the details for the code under test are within the short-term memory of the developer making the ...
The internal data models are fundamentally different.
Fundamentally, in SVN, when you look at the history of a branch, you only see what has happened in that branch. So when you merge from branch B to branch A, the history of branch A will contain one large commit containing all the changes made explicitly to B since it was branched.
In the first versions ...
This old question just got marked as a duplicate of a new one, and since a lot of the answers reference some outdated ideas, I thought I'd post an updated one.
One thing that apparently wasn't very common five years ago was running CI tests on pull request branches before merging them into master. I think this reflects a changing attitude that although ...
I think removing an already integrated feature after a merge is hard with most VCS (or DVCS), so you should make sure that this situation happens as seldom as possible. Some ideas:
If you have a feature for which the approval is at stake (for example, you need a usability test first before you are sure that you are creating the "right" thing), make sure ...
The automated tools are getting better at making sure that the merging code will compile and run, thus avoiding syntactic conflicts, but they cannot guarantee the absence of logical conflicts that may be introduced by merges. So a 'successful' merge gives you a sense of false confidence, when in reality it guarantees nothing, and you have to redo all of your ...
The thing about pull requests is that it makes known that there are changes that someone wants to bring into the project.
If the owner/maintainer wants to cherry pick parts of the pull request, they can do that from that pull request.
And just because there is a pull request does not mean that the maintainer is not allowed, or incapable, of doing a rebase.
In DVCS-world commits are cheap and history is mutable. WIP can be as "dirty", as you want: and I can't see any reasons against "drop my current state in changeset for storing"
SVN history is linear, thus - you must to merge you drafts with changes from new revisions. DVCS use (natually) DAG, and additional head (commit+pull+up) for diverged history is safer,...
Using the master branch as the canonical source for code in production makes it easier for developers to clone the repository and immediately have production code in front of them. It's as simple as:
git clone your-repo
If a different branch is used for production code, then the master branch still needs to represent something, otherwise it will cause ...
While you have tried using a separate -prod branch with gatekeepers, it sounds as though the one repository is used to actually do the production builds. If the production builds were only done from a production repository, writable only by it's gatekeeper then the devs wouldn't be able to push to it. This puts a load on the gatekeeper, who would only push ...
This may not be as automated as your want but TortoiseHG will let you select what branch you want to merge and indicate that the branch is merged. The downside is that I do not think there is a TortoiseHG mode where you can see what branches are still unmerged. You'd have to scroll throught he graph portion of the history pane to see what is what.
Everyone here seems to agree that projects using DVCS have shorter release cycles over all, but it's still not certain that the adoption of a DVCS causes the shorter cycles: Correlation is not causation!
Distributed VCS and short release cycles are both relatively new technologies. Projects that embrace one are likely to embrace the other, while groups ...
What makes software release cycle shorter with DVCS, compared to CVCS?
I don't think there is necessarily a difference between DVCS and CVCS here, but rather a difference in the branching model that people adhere to.
From what I have gathered here and from my experience, people using DVCS tend to use more branches than people using CVCS. And if you develop ...
Has anyone encountered difficulties due to broken historical commits
Yes. Backports, reverts and bisects are harder.
So is reading the history (see below).
If so, is there a simple way to avoid such difficulties, without discarding individual commit messages and changes?
Not that I know, although branches are a decent solution.
However, I ...