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 ...
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.
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 ...
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 ...
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, ...
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 ...
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 ...
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-...
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 ...
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 ...
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 ...
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,...
As Tristan said, splitting the features into their own repositories is the best practice, if possible. However, there are alternatives if the code is too intertwined.
One is to use MOE, which is a program that basically automates translating a repository between an open source and a closed source version.
Another option is to create a Bob branch, then ...
Three things haven't been said in any of the answers:
Diffing inside a branch:
Diffing between an arbitrary pair of commits in a branch becomes extremely difficult when there are merge commits.
Merging one item at a time:
When you're resolving the difference between two branches, a merge typically happens all at once, and any merge conflicts you're left ...
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 ...
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 ...
No, it's not okay.
If you ever did a git bisect (and who doesn't love that killer feature), you know the value of a history where every commit builds.
If you have many commits during a bisect that don't build, you'll have lots of git bisect skips that make it difficult to find the last good commit.
If you finish a feature branch and merge it into master,...
When you merge or cherry-pick in git, you are creating a commit immediately. The operation is not complete until that commit is finished and part of the history.
Now, what would happen if git allowed you to gloss over your uncommitted changes in your working directory? You would have a (more or less) hard time to differentiate between the changes/merge ...
If your system tracks all features/bugs then you likely will have a ticket of some sort. But if your system only tracks bugs (for some reason?) and all new development is a free for all.
Some significant advantages:
Some VCS/ticket systems allow auto hyperlinks for the ticket number when browsing the commits in the issue tracker (this is super useful, see ...