Skip to content

Instantly share code, notes, and snippets.

@quantumproducer
Created March 23, 2018 15:18
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save quantumproducer/d4e3bf2daf304a3779e634dd7a3b5e6c to your computer and use it in GitHub Desktop.
Save quantumproducer/d4e3bf2daf304a3779e634dd7a3b5e6c to your computer and use it in GitHub Desktop.
how-to-git.txt
going to write here from DM
[6:28 PM] qp: So here's what I've found has worked for me, and worked for many teams I've worked with
[6:28 PM] qp: master is authorative, customer facing
[6:28 PM] qp: dev is the main development branch
[6:28 PM] qp: whenever you deploy to customer, push to app store, etc, you merge to master from your dev branch
[6:28 PM] qp: and then you do git tag MYVERSION.NUMBER like git tag 1.1
[6:29 PM] qp: then make sure to git push --tags
[6:29 PM] qp: so in the future, if your boss says "big problem, roll us back to version 4.2.0" you can say "ok, sure, git checkout 4.2.0 and deploy that
[6:29 PM] qp: so about that dev branch
[6:29 PM] qp: that should be your base of operations
[6:29 PM] qp: it's helpful to git checkout -b feature/player_controls
[6:30 PM] qp: instead of just "controls"
[6:30 PM] qp: so you leave room in the namespace for -b bugfix/player_controls_broken_jump
[6:30 PM] qp: it's a little verbose but a little verbosity applied consistently can give you peace of mind in the future(edited)
[6:31 PM] qp: So you work on your feature branch, when finished, issue a pull request into dev
[6:31 PM] qp: let your team review it, merge it
[6:31 PM] qp: if it's just you, just merge it on in
[6:31 PM] qp: if you have to work on feature A > B > C where C depends on B depends on A
[6:32 PM] qp: then you should branch from your feature branch into separate branches, ala feature-dev/controls_jump
[6:32 PM] qp: finished? merge back into feature/controls
[6:32 PM] qp: then branch out into feature/controls-roll
[6:32 PM] qp: and when you're all done, issue a PR from feature/controls back into dev
[6:32 PM] qp: this is so you don't prematurely submit a PR into dev with unfinished features
[6:33 PM] qp: it's good hygiene to merge from dev back into your feature branch before you submit your PR
[6:34 PM] qp: so your coworkers don't have to untangle your mess
[6:34 PM] qp: I sometimes will make a local "devmerge" branch on my machine, checked out from my featur ebranch
[6:34 PM] qp: attempt a dev merge from there
[6:35 PM] qp: eg
git status >> feature/controls
git checkout -b devmerge
git merge dev
error : conflicts in x, y, z
git merge --tool=opendiff
git checkout feature/controls
git merge devmerge
git branch -d devmerge
git push origin feature_devmerge
Issue PR
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment