CODEWITHSUNDEEP
gitgit-merge
eugene
eugene

Reputation: 41665

How to keep master history short and clear in git?

I have 2 remotes repository for a project.

1(origin) is my private repo where I make my modification to the project.
2(upstream) is the original github repo where I cloned(--bare) from.

From time to time, I get updates from the upstream and merge it to master, and it works well.
However when I see the commit history, all commits from both repositories(origin/upstream) are shown and its hard to tell what changed where.(especially our inhouse commits)

What's the good strategy to keep the master branch history clean?

I came up with an idea, but wasn't sure if it will work or good enough.

create a branch in origin repository to be used solely for merging-in upstream changes.
After merge upstream to this branch(let's call it merge_branch), I merge the merge_branch to master hoping to see only 1 aggregated commit.

Upvotes: 1

Views: 102

Answers (1)

Balog Pal
Balog Pal

Reputation: 17163

It's unclear to me what your current method really is... However what you describe as the new idea sound like the usual way.

Your repo should look like this:

  • master branch with the final state (tracks origin/master)
  • upstream branch (tracks upstream/master)

At start and later point you merge the upstream branch into master. Direct commits on mastr are your work. It's up to taste whether you push the 'upstream' branch itself to origin too, the merge commits normally are informative enough.

EDIT: After discussion it's getting clear what you're after. To see the whole upstream as a single commit, you have to merge with --squash.

It is something I'd consider an unusual use of upstream, but can make sense. If you do that, I suggest to run the upstream branch as above to keep ability to see original commits too (both on local and origin), merge with squash and in commit message note the hash of the upstream branch (deleting the commit list).

Upvotes: 1

Related Questions