Created
March 23, 2018 15:18
-
-
Save quantumproducer/d4e3bf2daf304a3779e634dd7a3b5e6c to your computer and use it in GitHub Desktop.
how-to-git.txt
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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