However, the pull request has conflicts (dotted red line) because the title was already changed. There’s no code involved, just text, so it doesn’t seem like a big deal, right? It’s immediately submitted for code review. There would be a merge conflict into Master, but for whatever reason it didn’t get merged to Master for testing. git checkout prodįeature 2 is merged to Master for testing (C6): git checkout masterįeature 3 is a minor change and you want it out quickly. There’s an explanation section about -no-ff below and why you always want to use it when merging into clean branches. Git commit -a -m "Feature 3 - changed title"įeature 1 is ready for testing, so merge it to master (C3): git checkout masterĪfter a code review, Feature 1 is deemed ready for Production (C4). # Edit theme title differently in style.css In the real world, you’d never purposefully assign two developers the same task concurrently, but we’re going to do this to artificially introduce a merge conflict. Git commit -a -m "Feature 2 - changed author"Ĭreate a third branch from Production, and edit the title again (C7). Git commit -a -m "Feature 1 - changed title"Ĭreate another branch from Production to edit the theme author (C5): git checkout prod I’ll explain as we go along.Ĭreate our initial repository with one file (C1): mkdir git-merge-revertĬreate the Production branch from Master where reviewed code will go from now on: git checkout -b prodīranch Feature 1 from Production and edit the theme title (C2): git checkout -b feature1/change-title We’re going to recreate the following scenario. Skip any highlighted git push/fetch commands, unless you’ve also set up a remote (origin) repository at GitHub or similar. If you’re a hands-on learner, you can reproduce this entire scenario in a local Git repository by running the preformatted commands in a terminal window. This happened to me recently so I wanted to share what I learned, in case you find yourself in the same situation. When something gets screwed up in Git, it can bring everyone to a screeching halt. With larger teams, it can seem like things are moving fast, because they are. They can get merged into Master at anytime, and merged into Production after a code review. There’s sometimes tens of these in progress all at once. They always start from the clean Production branch. Feature – A short-lived branch for one particular feature.Master – “Dirty” branch where developers can merge changes for testing typically automatically deployed to a development server.Production – “Clean” (reviewed) code that will usually automatically be deployed to a server where it can be QA-d and or client-reviewed.The names here are arbitrary, but these are some conventions we use: In practice, it allows us to have greater development speed and product stability with a larger team. The branch and merge strategy allows for multiple developers to work on a multitude of various features concurrently. Here at WebDevStudios (WDS) we use a GitFlow-like process during development.
0 Comments
Leave a Reply. |