CODEWITHSUNDEEP
gitgit-branchgit-stash
timato
timato

Reputation: 182

Tracking changes using git during code review (stash vs. branch)

In the interest of keeping code reviews small and concise, I've submitted a smaller code review than a full feature. It is the cleanup before a larger change, but to avoid cluttering up the final review with the cleanup, I've made this review.

My later work will build on this currently active review, and there will be changes that I need to make as a result of the review. However, I would also like to continue working on the final feature while this code is in review.

How I can properly track my development on the feature while still remaining able to make changes for code review.

Current scenario:

master -x-x-x---x---|
feature      \-x-x-x| code review

Future scenario (branching)

master -x-x-x---x---|
feature      \-x-x-x|-x--x--|
  feature2          \x--x--x| code review complete (merge)

Future scenario (stash)

master -x-x-x---x---|
feature      \-x-x-x|-x--x--| code review complete (merge)
  work on feature branch, stash changes if needed to make code review updates

I think the branch model makes more sense, but creating another branch with the same name and same purpose seems to violate some sense of "git propriety"

Upvotes: 2

Views: 558

Answers (2)

timato
timato

Reputation: 182

What I ended up doing was as chepner and larsks suggested:

I had already made some changes, so I needed to stash what I'd done first. On branch feature.

git stash

Then created the code review branch, which has only what I had already submitted to the review.

git checkout -b feature-cr

Finally, put my stashed changes back onto my feature branch

git checkout feature
git stash pop
git commit -am "Some descriptive commit message"

Upvotes: 1

chepner
chepner

Reputation: 531165

I think branching is the right approach; you might just want good branch names, and instead of making a new branch for your work, use the new branch to "freeze" a snapshot of the code for the code review.

Say your repository look like this when you want to submit feature for code review.

* -- * -- * -- * -- * -- * -- *  master
      \
       * -- * -- * -- * feature, HEAD

Just create a new branch called (cr/feature), where cr is short for (you guessed it) "code review".

git branch cr/feature

Now your current branch head has two branches referring to it.

* -- * -- * -- * -- * -- * -- *  master
      \
       * -- * -- * -- * feature, cr/feature, HEAD

As you continue work on feature, you don't affect the code undergoing code review.

* -- * -- * -- * -- * -- * -- *  master
      \
       * -- * -- * -- * -- * -- * -- * feature, HEAD
                      |
                    cr/feature

Once the code review is complete, does the reviewed code get merged into master?

git checkout master
git merge cr/feature
git branch -d cr/feature  # Optional


* -- * -- * -- * -- * -- * -- * -- *  master
      \                           /
       *   --   *   --   *  --   * -- * -- * -- * feature, HEAD
                                 |
                             cr/feature (if not deleted)

This way, the code reviewer(s) never see your continued work on feature until you submit it for code view by explicitly creating a branch for them to look at.

If there are updates needed to the reviewed code, you can add those to the cr/feature branch:

* -- * -- * -- * -- * -- * -- *  master
      \
       * -- * -- * -- * -- * -- * -- * feature, HEAD
                      \
                       * -- * cr/feature

and either merge cr/feature back into feature

* -- * -- * -- * -- * -- * -- *  master
      \
       * -- * -- * -- * -- * -- * -- * -- * feature, HEAD
                      \                  /
                       *      -----     * cr/feature

or rebase feature on top of the code review branch

* -- * -- * -- * -- * -- * -- *  master
      \
       * -- * -- * -- *       * -- * -- * feature, HEAD
                      \      /
                       * -- *  cr/feature

Upvotes: 2

Related Questions