How to Exclude Commits on a Merge Based on Conditions in Git

code-reviewsgitproductivityteamwork

My eyes are destroyed. I am using a screen reader.

We are using git as our version control system on our project. We host our own server and use ssh to access it. We put each module under separate branches, then merge them all to a branch called dev for testing. Then when we determined that everything is stable, we merge dev to master.

Lately I am finding we are using remote branches in an unusual way. For example, suppose my partner found a bug he couldn't fix. Tipically I would ask him to read the code and suggest some fixes. If that is imposible (e.g. he does not know what to read or code is too long), we do the following.

He commits the file containing the bug and pushes it to the remote branch.
I would then pull his last commit and read his code and try to understand the bug.
This repeats over and over until the bug is fixed. Sometimes I would ask him to push related files to the current file (E.G. maybe the problem is how json data is formatted so I have to read the file that submits the json object to the current file.)

For me, Git made this process very easy. I now have a way to personally inspect someones code without annoying people to reread a large portion of their code to me if I want something clarified. However, I believe we are using commits in a very bad way. I couldn't easily delete those commits in the local branch because they are already pushed into the remote branch.

My first solution is: when merging my module to dev, I would exclude all commits that are not real commits using some identifier or some range. The problem is the commits are scattered depending on when the bug occurred and what time. Rebasing them could be very time consuming and unproductive to the other developers on the team. I don't know how to achieve what I want.

What should I do?

Best Answer

Keep the commits. They are REAL commits.

When viewing the history, only look at the branch merge commits. These contain all the changes in one commit.

git log --merges

Check out the other advanced git log features which might help with a screen reader.

https://www.atlassian.com/git/tutorials/git-log

Related Solutions

Git – Code Review Process Using GIT

A simple but effective model is the GitHub pull request model, where contributors file "please merge in my code" requests. A maintainer reviews the changesets and decides if they need more work or if they are suitable for merging. He then may merge into the master branch. Committers are generally not allowed to push directly to the master branch (this can be customized to your tastes, we allow "minor" commits to go directly in).

Version Control – How to Merge Bug Fixes from Trunk in Old Branches

The Git Flow assumes you only have a single supported release, with the master branch always pointing to the latest release. Since you support multiple releases simultaneously, you cannot copy that workflow 1:1. Nvie's Git Flow is a very good example of a branching strategy, but you must adapt it to your needs. Most importantly, you will have multiple active release branches.

When you identify a bug, you will have to do some testing to determine all affected versions. It is not sufficient to write the fix first, then merge it back into the release branches as a hotfix. Usually, you'll end up with some continuous range of affected versions. Very old versions might not contain the bug, newer versions might have gotten that bug fixed accidentally. You will need to verify the bug on each version so that you can verify it is actually gone after the fix. If you can express the bug as an automated testcase, it's pretty straightforward to find the problematic commit via git bisect, or to run the test for each release:

for release in 3.8 4.1 4.2
do
  git checkout $release
  if ./testcase >release-$release.log
  then echo "$release ok"
  else echo "$release AFFECTED"
  fi
done

Now, you used to write the fix on trunk/master. This is problematic because the buggy part may have changed between versions, so a patch will not usually apply to an older version. In particular, code in master might depend on any features available in master, which might not have been present in older versions. It therefore makes a lot of sense that a Git commit references its whole history, not just the change set. When merging back, it will pull in all the history it depends on.

Using cherry-pick or rebase ignores this history, and records a new commit with the same changeset, but a different history. As pointed out, this will not work if your codebase has diverged.

The “correct” solution is to write the fix as a hotfix on the oldest affected release. Then, you merge oldest release into the second-oldest release. Usually, a newer release would contain all commits of an older release, so this is OK. If things have changed, you now have a chance to manually resolve the merge conflict. Then you continue merging each release into the next-younger release until you are done. This maintains proper history and avoids a lot of unnecessary work, while only requiring effort that has to be expended anyway. In particular, this incremental merging gets you closer to the current development state in small steps.

As a diagram:

| o normal commit |
| x hotfix        |
| ⇘ merging       |

3.8 --o-----------------x
       \                 ⇘
4.1     o--o--o-----------x'
               \           ⇘
4.2             o--o--o-----x''
                       \     ⇘
develop                 o--o--x'''--o--o

Best Answer

Related Solutions

Git – Code Review Process Using GIT

Version Control – How to Merge Bug Fixes from Trunk in Old Branches

Related Topic