I've settled into what I think is an effectively simple git workflow that I thought would be helpful to share.
Let's say I am working on a new feature. First thing I want to do is make sure my local copy of the codebase is up-to-date:
$ git pull master
I'll then create a new feature branch. In my experience, 99% of the time I am branching off of master:
$ git checkout -b an-awesome-new-feature
But it’s just as easy to branch off another branch:
$ git checkout -b an-awesome-new-feature some-other-branch
Within this new branch, I can spike on the new feature, and if things get hairy I can blow it away and start over. I'll commit often. Most of my commits during the spike or early phase of a feature will look like:
$ git commit -am "WIP specs"
If I am pairing, I will be more descriptive with the commit messages. But when I am coding alone, these pre-PR commits are for me, and are not meant to be used for any meaningful code review. When I am satisfied that I the work I've done will eventually become a PR, I'll push my branch to a remote:
$ git pushr
pushr command is a nice little shortcut from the dotfiles I use. It creates a remote branch with the same name as my local branch, in this case,
an-awesome-new-feature. After the initial
git pushr, I can just do
git push and it will push to the remote branch.
The "do some work, test, commit, push" loop happens until I am
satisfied that the feature is ready for a pull request. If a new feature
was merged into
master that will effect my feature, I'll
pull the changes in, and then do:
$ git rebase master
Recently I've gotten into the habit of rebasing my
feature branches whenever anything is merged into
even if I don't think they will effect what I am doing. I've done this
mainly because, if there is a conflict, I'd rather be in merge hell in
the middle of working on a feature than at the end of a feature. It's dispiriting when you're about to open a shiny new PR and you realize it won't merge cleanly.
At this point I
and squash all of my commits on the
an-awesome-new-feature branch into one commit. This commit
message will be as informative (detailed) as possible, since it will become the
basis for the pull request message.
Once that's done, I'll force push to the branch with my new rebased history:
$ git push --force
I'll then open my pull request. I will push new commits to the branch after the PR is open, based on feedback. Once I get a :shipit:, I like to re-squash all post-PR commits back into the first PR commit.
been some discussion on our team about the merits and demerits of this
approach. I like to have one commit per PR when it's possible. It seems
cleaner to me. But there's a good argument for not doing this, since
those post-PR commits were changes made based on feedback, and that
feedback history is important to have. Personally, I feel the comments
in the PR on GitHub are sufficient as far as history goes. Usually if I
want to dig deeper into what went into a new feature and why, I'll go back and re-read
the PR message and subsequent comments, as opposed to reading commit messages in
git log. But that's my
own preference. The other way is fine too, in my opinion.
In either case, once the PR is merged, the feature branch is deleted
locally and remotely. The
master is updated locally via
git pull, and the cycle repeats.