when merging git branch, how to avoid the commits logs in a branch?

if another developer branches out on branch DEVELOPER_A, and makes a lot of commits on that branch, when he’s done, I want to merge his work onto master. but I don’t want all his small commits to show up on the master branch history, and only care about the last commit.
so is there a way to “squash ” his history on branch DEVELOPER_A when merging that branch?

I could get a patch on developer_A branch, and apply to master, but I’m afraid git will lose track of the fact that the result is merged from developer_A branch, and merely thinks that this is some independent change

  • How do I create a branch and a pull request for a previous or old commit?
  • reset --hard git remote branch to SHA in remote reflog but not in local repo
  • Storyboard Deleted by Git and “You need to resolve your current index first” error with Xcode
  • Servicing Branch in Standard Branch Plan
  • Commit a change to more than one branch in Git
  • Undo Git Track Command
  • Thanks
    Yang

  • How to import Eclipse project with source control to Android Studio without changing the directory structure to the Gradle one?
  • Easy-to-backup version control for windows single developer
  • I committed and pushed a useless big bitmap - should I repair the repo?
  • Merging IntelliJ tasks with no-ff
  • access to jenkins shared pipeline library through a corporate proxy
  • GIT: Any way to commit on multiple repos?
  • 2 Solutions collect form web for “when merging git branch, how to avoid the commits logs in a branch?”

    You can do this in several ways, but the most obvious is to use a squashed merge.

    git merge --squash <other_branch>
    git commit
    

    Note that git will pre-populate your merge commit message with the log messages from the squashed commits, but you are free to edit or delete the messages to suit yourself.

    Most of the time you want to clean up the history, not just mush everything together. The tool for that is git rebase (use with extreme care, and never on published stuff, as changing history creates havoc for your downstreams).

    OTOH, it is very useful to have a detailed history (micro-commits) at hand for chasing bugs (look at git bisect).

    Git Baby is a git and github fan, let's start git clone.