Using git as a storage intermediary (and maintaining a rich and sane log history) [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

开发者_高级运维

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 6 years ago.

Improve this question

I develop on 4 machines, 1 at home, 2 at work - windows/linux. Often I want to use my git repository just to move code around, code in flux. This also covers my use-case for backing up code to a central raid-backed remote repository.

I don't want to leave any comments or pushes in the commit log when I am using it for this purpose. In other words, the commit logs should only represent deltas that are feature or bug-fixes. Since git is a swiss army knife, what are some of the ways of achieving my use-case ?

If you are going to demonstrate the use-case please list the commands, and some commentary if there are multiple approaches.

Some commentary of compressing multiple commits into a single one in the log history would also be useful, since I have left behind a trail of commits as it stands :D

edit

If you know of complementary ways (to the answers allready presented) of achieving such use-cases please provide an answer. I will make it a community wiki if there are lots of good answers.

---

You can create a branch and pass that branch around among your instances. When you delete the branch it will be gone. you can use git rebase -i to merge your multiple, fluxxy commits in to a smaller number of good commits. You can read up on this just about anywhere.

With git and rebase you can get into the habit of committing "all the time", usually anytime something works (or even if it doesn't and you want to be able to get back to a "known bad" state). Then when you have something close to done you can collapse those into a single commit, or multiple (if you take the time to make sure each commit stands on its own).

---

The usual way is git rebase -i HEAD~20 (where 20 is the number of commits back you want to go) and change pick to squash where you want to combine commits. There are probably tools out there that will do this for you automatically.

Bonus git feature, git bisect for finding out which 10-line commit is the one that broke you. :)

---

As the other answer says, you probably want to create a new branch for your current work-in-progress as you're committing so frequently. This branch is the one that you push and pull between your private repositories. You might create that branch with:

git checkout -b wip master

Then when you want to commit, just do it with a:

git commit -m "Work in progress"

... or something similar.

If you're happy that you want to group together all the changes on the wip branch into a single commit, you can do:

git checkout master

# Rather than create a merge commit or a fast-forward, stage the
# effect that the merge would have to the tree:
git merge --squash wip

# Check that that looks sensible:
git diff --cached

# Now commit and write a proper commit message describing the changes:
git commit

After that, you should have a single new commit on master that groups together all the changes that you'd made on wip. If you do the same thing subsequently, you should still only get the additional changes that the merge would introduce as a single commit, so you don't need to worry about rebasing wip - there may be some conflicts to resolve, of course.

---

I think that approach (successive uses of git merge --squash wip) would work, but, if were you, I probably wouldn't do that in practice. That's because I'd like to leave behind topic branches for the new features that I decided to merge into master and be able to see those merges. Instead, I would probably take a slightly more involved approach:

• Work away on the wip branch, creating lots of tiny commits.
• Stop when there are some changes that make logical sense together and that can be grouped into commits and merged into master.
• Think of a name for that new feature or change represented by those changes, e.g. add-menu-bar.
• Create a new work-in-progress branch based on the current wip, for example with: git checkout -b wip2
• Use interactive rebase to reorder and squash your commits so that those that will be part of add-menu-bar are earliest in the history after divergence from master: git rebase -i master. Note that this is rewriting the new wip2 branch and leaves the original wip branch as it was.
• Find the object name (SHA1sum) of the last commit in that branch that you want to be in the topic branch add-menu-bar - let's say that's f414f31. Then create the topic branch at that commit: git branch add-menu-bar f414f31
• Now merge that new topic branch into master with git checkout master && git merge --no-ff add-menu-bar.
• Push your new master to anywhere that you need to.
• Switch back to wip2 and rebase it onto the new master: git checkout wip2 && git rebase master.

Now you work on the new wip2 branch instead, and that's the one that you push and pull between your repositories. The reason for creating a new work-in-progress branch is that then you don't have to worry the business of force-pushing the original wip branch to the other repositories, rebasing or resetting the branch there, etc. etc.

---

squashing is probably what you want

You can squash commits on merge (includes pull) or rebase (interactive as well)

git merge --squash

git rebase -i