-1

I'm using Source Tree as Git GUI of choice. I'm trying to implement git-flow system, meaning that most of the commits will be done in feature branches. As you can see on this image, creating feature branches, pushing commits and merging them back to dev branch works fine.

The problem is: if I am to squash my commits into one (either via Source Tree or regular git commands), finishing the feature makes it appear as if the commits were done on the dev branch.

Here is an example screenshot - the red branch is test feature that wasn't squashed, while "Squashed commit" and "commit 1" are commits that were squashed and merged same way as the previous branch was. The "merge" commits weren't included in squash, but nevertheless they are gone. I am yet to understand if that's how they are supposed to be displayed or I'm actually rebasing those changes onto dev branch somehow. Any help or advice is appreciated.

UPDATE

To no avail, after a series of experiments I am still encountering the problem - squashing commits via git rebase -i HEAD~amount_of_commits causes a discrepancy in either Source Tree or git itself. Using the "finish feature" button, which issues following commands:

git checkout develop
git merge feature_branch

or performing the same commands manually via git console results in a situation where after a git merge a "Merge branch feature/feature_branch into dev" commit is not created. The squashed commit is displayed as part of dev branch and it has the "dev" tag in Source Tree GUI. At first I thought because maybe that's how it displays branches with just one commit, but no, creating a feature branch and merging it after just one commit provides correct output. Perhaps using a different merge command might fix the situation, but I'm worried as to why Source Tree would work like this then. I still believe the issue if my git rebase command and there is a mistake in how I perform it. Any help is appreciated.

Ilya Solovyov
  • 1
  • 5
  • I think we need to see what commands you're using with the branches you're squashing. In particular you say "The 'merge' commits weren't included in the squash..." which I'm not following; do you mean that you're merging the branch and *then* doing something to try to squash it? – Mark Adelsberger Jul 13 '18 at 13:36
  • Thanks for your comment, I will try to provide as much info as i can. The average pipeline would be: git checkout -b feature_branch; *N commits*; git rebase -i HEAD~N; the first commit is set as picked, while the other are set as squashed; after the commits are combined, I push it to remote, checkout dev and perform git merge feature_branch. This is all according to https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow, and I believe Source Tree does the same under the hood. – Ilya Solovyov Jul 15 '18 at 13:00
  • What I meant by "merge commits not being included in the squash" was the fact that non-squashed branches have a finishing "merge branch feature_branch into dev" commits post-merge, while the squashed branch does not, despite the fact that merge command is called. The squash if, of course, performed pre-merge. If you still see a problem with my commands, I'd like to ask you to provide me a test combination of commands so I can output the results in order for us to pinpoint the problem. – Ilya Solovyov Jul 15 '18 at 13:05

1 Answers1

-1

To everyone who's struggling with the same problem: apparently this is an undocumented feature, not a bug.

Source Tree uses git flow toolkit, and its scripts are set to dynamically determine whether fast-forward should be used, just like in regular git. Fast forward prevents the merge commit and simply replays your changes on your checked-out branch. In order to preserve the branches, you have to manually call 

git merge --no-ff feature/feature-branch

which is something you'd expect git flow toolkit to do. Apparently, it doesn't apply --no-ff parameter if you're making a single-commit feature, UNLESS you've made commits to your dev post-branch creation (which is the reason why I thought merging single-commit branches works fine unless squashed).

According to https://community.atlassian.com/t5/Git-questions/git-flow-merge-no-ff/qaq-p/404062, you're able to modify underlying scripts manually, and there is no other way to automate this process. Checking "Do not fast-forward when merging, always create commit" under Tools->Options->Git did not change current strategy.

Ilya Solovyov
  • 1
  • 5