Git best practices for a react-meteor app

Hi guys, I wonder how do you manage your git efficiently when developing a meteor-react app? I try to keep my modules as small and separate as possible. So do you create branches for each new feature you develop, and commit changes a file or you commit each change to a file, and so on, please tell me such little tricks and nuances you came up with.

Heya! I’ll chime in, though git repo management styles are as diverse as people’s opinions. :slight_smile: My own method is a simplified version of Git Flow.

I’ve got two branches that are always present: master and develop. Let’s say at the moment, I have v1.2.0 of my app in production, and master and develop are pointed at the same ref. I want to work on a new feature, so I do this (while develop is checked out):

$ git checkout -b my-new-feature

I work on it and commit as needed. That could be one commit, four commits, etc. Once I’m finished, I push my branch (I use GitHub):

$ git push -u origin my-new-feature

I then go to my GitHub repo, and make a new pull request, merging this feature into develop. I could do this locally, but I like to have a record of it in GitHub. After the PR is merged, I delete the feature branch, then:

$ git checkout develop && git pull && git branch -d my-new-feature

And repeat for every new feature or bugfix I want to work on. When I’m ready to launch a new release into production:

$ git rebase develop master
$ git push

And then deploy! I’ll also go back to GitHub and draft a new release, e.g. v1.2.1, then pull that down… AND, if I’m deploying to Galaxy, which gives back version numbers, I’ll incorporate that into GitHub so I can match up Galaxy deployment versions with my code:

$ git fetch # pull down GitHub release
$ git tag production-v48 # Galaxy version number
$ git push --tags

Working in this way keeps master clean, in case a major bug pops up in production that I need to fix right away, and develop is in an unstable state. So if a bug pops up, no problem:

$ git checkout -b major-bugfix master

(fix bug and commit to major-bugfix branch)

$ git push -u origin major-bugfix

(do PR on GitHub, merge into master directly, deploy to Galaxy or wherever, bump version #, all the stuff mentioned above)

$ git checkout master && git pull
$ git rebase master develop
$ git push # we're pushing develop here, since the rebase above automatically switches you to develop

I think I covered everything. It’s a lot, but it keeps me super organized. If anyone has any tips on streamlining my process, I’d love to hear them!


Side note: I got obsessed over dead branches hanging around and kept running git remote prune origin every once in awhile, till I discovered you can just put that option inside your project’s .git/config file:

[remote "origin"]
	url =
	fetch = +refs/heads/*:refs/remotes/origin/*
	prune = true

And it will auto prune branches after they’re long gone, whenever you do a pull.

1 Like

Maybe everyone else is more git-hardcore than I am, but if you are following the approach @ffxsam does (which I do, almost exactly), it can often be tempting to do something like:

git checkout dev
git checkout -b newFeature

Then make a bunch of progress on said newFeature. Then see something small/superfluous like a console.log or typo, etc. and make the adjustment in the newFeature branch. Trust me when I say that this is a slippery slope. Another easy mistake here IMO is to change package versions in order to get your newFeature working.

Instead, you’d want to:

git checkout dev
git checkout -b newFeature

Make progress. Notice the small issue, or that you need to update a package.

git commit
git checkout dev

Correct the bug/update the package.

git commit
git checkout newFeature
git merge dev

This one came back to bite me a few times when trying to track down where I introduced something I shouldn’t have, which is super difficult if you allow yourself to get outside the scope of your branches.

1 Like

Yeah, one has to be careful to get out of their feature branch to make a fix to production. For me, it would look like:

# on feature branch my-cool-feature 
$ git commit
$ git checkout -b dumb-typo-hotfix master
# make changes to code
$ git commit -a
$ git push
# go to GitHub, open a PR, merge dumb-typo-hotfix into master
$ git checkout master && git pull
$ npm run deploy # Galaxy deploy
$ git rebase master develop && git push
$ git rebase develop my-cool-feature
# keep working (we're back on my-cool-feature branch)