Can I send changes of git staged area for code review (to any code review tool)?
I learned that git has notion of different file states: 1. New 2. Modified 3. Staged 4. Committed
After searching a lot, what I have found is if I want to send for code review to any tool, I have to make commit to local repository and push it to some central repo set for code review (by any code review tool eg Gerrit).
Now, suppose file was in state A before starting code review process and it went through 10 more reviews rework ie 10 more modifications ie 10 more commits to local repository and finally file is in state B, which should finally be committed.
From state A to B 10 commits were done.
Assume of these 10, 4 commits were on same section / part of file.
So, finally, when I will push reviewed and accepted file's final state B to main central repository I will have to make 10 commits of which some intermediate commits took rework ie unwanted commits.
But I don't want those unwanted commits.
From what I can think is I am interested in final state B to be pushed to repository with only one commit.
So I am looking for any such approach / tool which allows git staged changes to be sent for reviewed. Reviewer will review. If he rejects and suggest some changes then I unstage previous changes. Apply suggested changes, stage those changes and again sent for review.
Thus finally when code reviewed accepts I will make single commit my staged changes and will need only single final push.
It is not possible to push uncommited changes in a git repository. However you could use different branches to achieve what you want. You could work on a development branch, and make as many commits as you want. You can push them to a certain development branch on the remote server. After the reviewer accepts the changes, you can merge the commits into the main branch. If you want, you can use git rebase to merge the commits into one single commit.
git push origin stash@{0}^1:refs/heads/tmp/for-code-review
That will push your stashed index to be reviewable
here are reasons why it's better to use a uniquely created, separate branch:
To me, I don't feel like I really need to "convince" anyone to use branches instead because everyone who tries using stashes like this (or some other way) will figure out for themselves that the right/better/easier way is to just use side branches for work/code-reviews. aka git branch bugfix/xyz; edit...; git push origin bugfix/xyz;
git branch bugfix/xyz; edit...; git push origin bugfix/xyz;
I believe most code review tools will take a diff, so just use 'git diff' to produce the appropriate diff of your code to be reviewed.
As for merging your multiple commits into one, well, there's more than one way to do it:
You may want to look on the manpage at the --squash
option to git merge
. Or read this SO article.
Alternately, you can do all the commits you want locally on your dev branch but before you merge to mainline, use git rebase
to squash them together. See the manpage for details or read this SO article.
上一篇: Git删除分支和所有相应的更改