git: more efficient way to do this

问题

This is my normal workflow with git-svn:

create a branch for an issue
commit after doing some work on branch
checkout master
svn rebase
checkout branch
rebase master
checkout master
merge branch
dcommit

My goal here is to keep my history in a straight line, and also trying to minimize the headache of merges.

Is there a way to do this with less steps?

回答1:

There's no need to do your rebase in the middle, and certainly no need to swap to the master branch to do so. My workflow achieves the same and is thus:

Create a branch for an issue: git checkout -b issue remotes/trunk (that remotes/trunk can be omitted if I'm already on the branch I'm interested in).
Do some work, and commit it.
Push it straight to the Subversion repository: git svn dcommit. This will only fail if files you've edited have been changed. If they have, you'll get an error, so do a git svn rebase then try your git svn dcommit again.

Note there's no need to merge this into your master branch first.
Checkout the master branch: git checkout master.
Rebase the master branch: git svn rebase.

Optionally, delete the issue branch; the master and issue branches should now be identical, as git svn dcommit does a git svn rebase immediately afterwards.

You can do your git svn commands from any branch; the system will work out where to commit to or rebase from based on the parent Subversion branch. If you want to check what Subversion branch it's interested in, run git svn dcommit --dry-run

In particular, there's nothing particularly special about the master branch. Indeed, I frequently ignore it and skip steps 4–5 above. I'll just swap from one issue branch to another and never bother bringing the master branch up to the Subversion tip.

回答2:

You have 2 things at odds here. To keep your history in a single straight line, you need to rebase. However, rebasing implies that you have to re-apply changes on top of a different code base. This can set off a chain of conflict resolutions that you may need to do for every single commit you are rebasing.

The only thing I can add to help you is that if you have rebased, you know you will have a fast-forward merge. In this case, you do not need to checkout that branch to move it forward. So to update a reference, you can:

git push . my-branch:master

This will update master to point to where my-branch is pointing to and will only work if it's fast-forwardable. Unfortunately it's not going to help you here as you require to be on the branches to do the actions you need.

Back to the question of your workflow, you will have more problems with conflicts than you would if you simply merge.

回答3:

You can try SubGit instead of git-svn.

SubGit is a server-side solution. It enables Git access to your Subversion repositories as well as Subversion access to Git repositories. One has to install SubGit into Subversion repository, i.e. basically add necessary hooks that does conversion on every push and commit:

$ subgit configure $SVN_REPOS
$ # Adjust $SVN_REPOS/conf/subgit.conf 
$ #     to specify your branches and tags
$ # Adjust $SVN_REPOS/conf/authors.txt 
$ #     to introduce svn author names to their git counterparts
$ subgit install $SVN_REPOS

After that one has a Git repository at $SVN_REPOS/.git which is continuously synchronized with its Subversion counterpart. When remote access is configured for this Git repository (e.g. via git-http-backend), one can use any Git workflow and any Git client with existing Subversion repository.

For your case it would look like this:

$ git checkout -b foo
$ git commit
$ git checkout master
$ git merge foo or git rebase foo
$ git push

Some more details:

SubGit is much more superior than git-svn in terms of merge-tracking, end-of-line, mime-type support, etc;
SubGit is a commercial tool with some free options;
I'm one of SubGit developers.

来源：https://stackoverflow.com/questions/10940213/git-more-efficient-way-to-do-this

标签

git

workflow

git-svn