Sorry if this has been answered or if there are docs out there but I wasn’t finding such a basic question in my search.
We have 3 branches, Dev, Test, Prod and a very small team. So far the approach has been changes in Dev committed, once confirmed, Pull request from Dev to Test. Verify in Test and if okay, Pull request to Prod. My question is, originally my Prod branch was based on the Test branch. I obviously have lots of work getting pulling into the Test branch, but perhaps only 1 of those commits or files is ready for Prod. If I do a pull request from the Test branch to Prod branch, am I getting everything? What am I missing? Does something need tagged as “PROD” or Committed specifically to stand out from the others?
Yes. If you merge one branch into another, you get everything on that branch. You cannot merge a single commit in isolation. You can cherry-pick a single commit, but that creates a new commit with the same changes, which will create duplicate commits when you merge later.
What I recommend is that you reconsider your branching strategy. The common approach is to work with topic branches. The very, very short version is: For each feature/bugfix/… that you work on, create a new branch. That way you can complete it independent of other changes. Merge it when it’s ready. You can still merge into a staging branch first, run final tests, and (if they pass) then from staging into production. But in general you’d want to be reasonably certain the final tests will pass before merging the topic branch.
See Git - Branching Workflows for a longer description, and there’s a lot more documentation on the matter if you decide to go for this approach.
Thanks for the response. I do understand what you’re saying. And I think if working within Git solely, it would likely be easier, but we are using Snaplogic. It’s an ETL tool that has a Github plug in. In a nutshell, it’s just not as easy to choose different branches. We basically set up the Snaplogic environment to be in sync with the Github branches i.e. Dev, Test etc. I am wondering though, since the Test branch coincides with the Snaplogic Test environment and has all code that is currently pushed from Dev and being QA’d. If I create another branch called “Staging” that should basically mimc Prod. Anything being pushed to Prod has to first get to Staging and the pull request would go from Staging to Prod. But how do I go about getting “Approved” code into Staging? A pull request from Test to Staging will pull everything again. And I’m stuck where I was originally. Rather than pull request, could I somehow “Commit” the code to the Staging branch? Sorry if I’m not understanding, but I’m really feeling stuck with Pull Requests as the only option.
That kind of sounds like you need a Snaplogic expert to solve that problem, not a Git expert. I don’t know the tool at all, according to Wikipedia it’s a commercial thing, so you might want to ask their customer support.
My point was to not have a testing branch, instead feature branches that would get tested, approved, and merged into staging separately. If you merge a feature branch you get only the changes on that branch, that’s my point.
Aside from messy history there’s another reason why you shouldn’t try to pick specific changes out of a singular testing branch: When you run tests based on the code in a branch you test the specific combination of code on that branch. If you apply certain changes in isolation you get code that’s different from what you tested and could behave differently. With feature branches you can avoid that issue by making sure the branches are up to date with the target branch (and tested that way) before merging.