I have a project on github with two branches (dev and master), where code was in sync prior to adding some new features to dev. For a few months, I've been adding new features on the dev branch, which consisted of changes/updates to existing files, deleting some files, and creating new files, all on the dev branch. Everything is working great on the dev branch and now it's time to apply these changes to the master branch.
Since there are a lot of changes, I am trying to see all the differences visually between the dev and master branches, so I can apply the specific changes from dev to master without missing anything. I don't want to override master with dev, as there are some master specific files, so just the new things in dev should be applied to master, but I want to do it where I can see the compared files visually to ensure everything is looking right.
Any idea how to accomplish this?
Create a new branch from develop named release/may6. This way, you can commit changes to release/may6 without actually impacting your master branch.
Commit any master-specific differences to release/may6 and use the GitHub compare UI to see the differences between your working release/may6 branch and master:
https://github.com/orgname/reponame/compare/master...release/may6
Once you are satisfied that this view shows the correct master-only differences between release/may6 and master, simply create a Pull Request from that same compare UI which merges release/may6 into master.
Related
Github has the option to allow a PR to be squashed when merged ("Squash and Merge")
Is there anyway I can configure the branch so it only allows the "Squash and Merge" option?
My scenario is this
we have a develop branch, that feature requests are pushed to
sometimes developers will forget to choose "Squash and Merge" and will commit their feature branch, with 10-20 tiny commits to the develop branch.
These changes eventually get merged to master, and feature history becomes hard to read
I have looked in hooks in branch protection rules, but didn't see any such option
Unfortunately the option to change what type of PR merge is available on Github is set on a per repo basis. Since PRs are a github thing, not a git thing, I can't think of a way that you'd be able to do anything with githooks either.
I don't see a great option for your workflow as long as you require the intermediate develop branch that eventually gets merged into master. Workflows that have multiple layers of PRs get messy on Github. The one real option would be that you require squash to merge on Github PRs and then the regular merge from develop to master happens outside a PR (could be local on a machine or via a Github action potentially).
But, your best option if this is really a big problem may be to modify your workflow. One common workflow would be that master is the development branch. Then when it is time for a release a release branch or tag, depending on your needs, is created from master. The you will have no issue turning on the repo wide requirement for squashing.
I have a scenario where I will sometimes need to cherry-pick some commits from our UAT branch into our MASTER branch. This is because the business sometimes will request that only specific "features" are moved from UAT to production. I need to be able to pick certain commits to move forward as PR.
The issue I am having is that when try to cherry pick from one the commits (from the UAT branch) to master, Azure DevOps give me the error...
"Encountered conflicts when cherry-picking commit "42af19". This operation needs to be performed locally."
I am able to do this same pattern against my UAT, QA and Integration branches, I only have this issue against our master branch. I don't have any conflicts in the source branch so I don't believe its that. I also don't have any special rules for the master branch that should keep me from doing a UI based cherry-pick.
I really can't have our developers do this locally so I am hoping for some sort of option where they can use the UI for this.
We are using ADO to host the repo for our Salesforce code. We use another system that handles the CICD pipeline.
The high-level background for this is that we have may have 2 or more PR's that have been promoted and deployed to UAT, but the business may request that we only deploy certain ones. So some PR's might remain open against master for a few dev cycles. The issue is when other PR's move through and we need to promote them from UAT to master, ALL of the changes are getting added to the UAT > MASTER PR due to the fact that the code in the PR's that are in the holding pattern have not been committed to master, so the subsequent PR's would pick up those changes and try to merge them in, and we don't want that.
The thought is that we could cherry-pick commits from UAT as a PR. These only only contain the files we actually want to deploy, not EVERYTHING.
Hopefully someone can help me out with this scenario as I am a little stuck.
Thank you all very much for your guidance!
I have been working with a similar branching strategy for Salesforce. Normally in this situation, we would do the following:
Create a branch out of master - it will be used only to resolve conflict.
git checkout -b gs-pipeline/...
Cherry-pick a commit there, you can space separate them if there are many
git cherry-pick COMMIT-HASH1 OPTIONAL-COMMIT-HASH2
Solve Conflicts manually, save files, stage them, commit and push
Open Pull Request from gs-pipeline/... -> master
Unfortunately, there is no easy way to solve this within UI as far as I am concerned.
However, when you would down merge from master -> uat(directly or via a separate branch) that may solve your issue. It should be safe as things on master/PRD should already be on UAT and all lower environments.
Setting up new projects and branch designs in TFS 2015. This detail may be significant - I'm using it for PowerBuilder projects, not .NET - VS2015 is used to set up branches and perform merges, the files themselves will be checked in and out in PowerBuilder. Far as I can see that shouldn't make a difference, but mentioning it in case I've missed something
Using the following sample layout:
Prod branches to/from Mod, down to Dev. New CO projects branch from Prod (so they always start with a fresh set of the latest live code), then merged (via baseless merge) to the DEV branch, and re-parented once the connection is set up. That way the users wouldn't have to remember to do a baseless merge; Dev will become the default merge target
Merges would them go back up from Dev to Mod, then back to Prod
The issue is that as a test, I tried the baseless merge after the branch, expecting no files to be merged, as nothing has changed yet in any branch. But the merge from the CO branch to Dev merged ALL files. Not an issue now since there's no changes in place, but would be quite a problem once several projects have been merged to DEV.
After that merge, I made a small change in the project and tried a merge; only the one changed file merged.
My best guess is that since the new CO branch was created after the Dev Branch, it was seen as everything in it is newer than the Dev branch, so it rolled over everything. Not sure how it would treat changes in Dev not seen in the Prod branch yet, haven't tested that scenario. It SHOULD at the very least tell me there's changes that I need to merge, but I fear it might just roll over them with the "new" files in the CO branch.
The question is, how can/do I tell the system that this new branch is "not newer" than the Dev branch? Does indeed the fact that these are PowerBuilder files somehow limit the ability of TFS of recognizing versioning in some way?
Or even more simply, is the branch layout I'm trying not the best method?
EDIT - here's the structure I'm currently using for my .NET projects - I was trying to use the layout above instead for the new code.
It uses the "Main" branch suggested below in the comments, but since I'm pulling "CO Branches" from Dev, I get code currently being tested, and not pristine Prod code. I'm assuming trying to branch and re-parent from Prod in this layout would result in the same scenario.
So is this the better way to go after all?
You may have a Main branch, which is the junction branch between development and release branches, representing a stable snapshot of the product.
You can branch from Main to Dev, Mod and Prod, when the work on Dev branch finished, merge from Dev to Main, when you want to release the product, merge from Main to Prod. So when you want to branch from the latest live code, you can branch from Main. In this way, you can merge from CO to Main, then Main to Dev or Main to Prod. All changesets will be reserved.
Me and my friend are two days into using Git now but we still lack the know-how to use it properly and utilize its full power though it is a tremendous step in the right direction, compared to using Facebook messages to sending and syncing files. We have searched over the net and most of the guides for Egit either assume you work alone or that someone else clones and branches off to their own repo. However we are collaborating on the same project (a 2D RPG) and don't know how to properly use Egit to work together. Some of the problems we face:
1. We had the exact same copy of the project, he changed some of the methods we used, I changed some of the classes and resources we use. He committed and pushed to repo first. Now I cannot push or commit or even pull because of conflicts in the files (repo vs local) which Egit complains must be resolved.
2. How do you properly synchronize code that you are collaborating on? Lets say either one of us is first out to push to repo, what must the other (the puller) do to make sure his own code is not completely overwritten, only accept parts that have changed, parts that we think should be changed.
3. Do we always have to make a (new) local branch, pull to this, see changes, and merge the changes we want with the master/main? How do you properly do this.
Any input is most welcome, we are already much more efficient with our broken knowledge, more will only do good :)
Ok here are my answers:
We had the exact same copy ... because of conflicts in the files (repo vs local) which Egit complains must be resolved.
First you should make sure you use separate branches so that you can always commit.
Then you have to resolve any conflicts when you merge.
How do you properly synchronize code ...
Use separate branches to make sure code is ok before you pull it into master branch.
Do we always have to make a (new) local branch ...
Yes, git is built on the assumption that this is the best way to work. "Everything is local"
This is the way I or we usually use branches:
Main dev branch (Master)
Project branch, used to merge in features added by this project. When all features have been added and seems to work this is pushed/merged into the master branch.
Developer branches, every developer has his/her own branch to develop a specific feature before pushing/merging that into the project branch.
What could sometimes be good to have is also specific release branches. I.e. when a project has merged all added features into the master branch and everything seems ok, a release branch is created for regression testing. This branch will eventually contain the released software when all testing has been done.
The benefit of doing a separate release branch is that the main branch can continue to be developed, but if a fast bugfix has to be done on an earlier release it can be done on that release branch and then later merged into the master branch.
//jk
I am new to version control. I often hear these words Merging and Branching. I also see different developers working in different branches.
Can someone explain the flow on this. What is the difference between Merging and Branching. When to go for Merging and Branching
Branching is about isolating a development effort in a specific history, parallel to the main one.
See "When should you branch?": you branch when you cannot commit on the current branch (because it would break the work of your colleagues)
Merging is about reconciling two different branches.
You merge when you want to take into account in your branch the changes of the other branch you need to merge.
The workflow depends on the tools.
SVN offers either merge-based development or trunk-based development.
Tools with easier branching capabilities (like Git for instance) offer a workflow based on the various development lifecycle steps:
In the concept of git,
Branch is just a pointer to a commit, and will be advanced to the new commit when you make new commit to that branch.
Git has 2 types of branches: local and remote.
git can merge any single commit, not only the head of a branch.
I take the most simple merging workflow as an example.
2 developers are working on a project.
They are working independently based on the same version.
They share the master (main) branch via a server when they complete.
The first developer commit changes and push to the remote branch first. The second developer then synchronizes the changes by pulling changes made by the first developer.
A merge commit will be automatically created.