CODEWITHSUNDEEP
gitversion-control
AxeEffect
AxeEffect

Reputation: 7431

Git: stashing instead of branching

On my daily work I've found myself doing a new code committing habit with Git: instead of creating a branch of the dev/master/main branches, doing my changes there and when I've finished then merging back to the reference branch by solving conflicts I just don't branch at all. Instead I do my changes locally on the reference branch, and when I have to push changes, in order to get the changes other people have done up to date, I stash my changes, I pull new commits and then I apply my stashed changes on top of these other people's fresh commits and solve conflicts (if any). Then I finally push changes. I found this practice easier and simpler than deal with branches.

Is this way of committing changes wrong, acceptable or even better than conventional branching? Why?

Upvotes: 1

Views: 112

Answers (2)

ivan.sim
ivan.sim

Reputation: 9268

There is nothing wrong with your prescribed workflow with git stash (and totally acceptable), because, remember, it is your local repository. You can do whatever you want to it as long as whatever you push to the rest of the world remains consistent. For example, don't rewriting history on commits that have been pushed to upset everyone else.

The important thing here to recognize is that branching and stashing are not mutually exclusive. If stashing serves your current needs, go with it, until more complicated scenarios surface where you will need to consider both branching and stashing.

A few things to keep in mind:

  1. Branching in git is a low-to-no ceremony operation. On my team, it's part of our daily workflow.
  2. Branching allows team members to share work-in-progress codes that are not ready to be pushed to master (or whatever your upstream main branch is). This, essentially, allows us to form subteams among team members.
  3. Branching allows us to submit pull requests to github while contributing to other projects, or requesting code reviews.
  4. I always keep my stash list small to avoid confusions in the future, by using git stash pop and git stash drop.
  5. There will still be merge conflicts with stashing.

Upvotes: 1

DRC
DRC

Reputation: 5048

Usually that is somewhat equal to rebase your feature branch on the one you are following, so for example you follow upstream master for a featureX, you then do:

git fetch --all
git checkout featureX
git rebase master

this will apply your changes based on the new pulled code.

If you already have stashes around you can convert them to feature branches with something like:

git branch featureX [<stash>]

I found more idiomatic to deal with feature branches than dealing with stashes, that for me go easily forgotten and you cannot push them around on your eventual remote development repo.

Upvotes: 0

Related Questions