I'm trying to identify the proper way of working with multiple branches on Gerrit that would match our workflow.
The way we work with branches right now is: we have master & feature branch. Master is the branch we want to polish and make it ready for release, while feature is obviously a field of intensive work. Now, in our particular case whenever somebody works on a bug fix, they:
create a change targeted for master branch
cherry pick it to the feature branch targeted change
once gerrit code review completes, submit both changes.
now the way i understand cherry-pick, it selects individual commit and merges it to the current change. if that is the case, i would expect to have no merge conflicts in the end, and indeed this workflow works perfectly with just GIT. Gerrit, however, most likely due to its nature (branches are not merged remotely the way these are locally and get a different sha tag) lists a tremendous number of conflicting files in the end.
Now, I resolved all these issues by applying merge strategy (ours on feature, theirs on master), but it does not feel right: if anything was not propagated, it just got discarded.
My question is: is there a safe workflow, similar to the above one, that would in the end produce a clean merge with gerrit?
I would say that it's better, in this case, to merge than to cherry pick.
A cherry pick adds the same changes but not the same commit. So while the source is the same on a cherry pick and merge the git tree is different. When the tree is different and you later do a merge git will think that the commit you previously cherry picked is missing and try to merge that change as well, even if the actual code is already there. That's probably why you get a lot of conflicts.
I would propose another way of working.
When you do normal work you develop on feature and push to Gerrit as normal.
When you do a patch (ie bug fix) on the stable production environment you do that directly on master (or local branches if you like but not on feature)
When the patch as been approved in Gerrit it get's merged into the real master and you can make a pull request to get that change to your local copy. Your version of master is now the same as Gerrits master
Now you would merge all new changes on master into feature. Make sure you do a rebase so that the patch ends up before anything you've already done on feature
Once it's time to deploy all new features you can merge feature into master, push to Gerrit (if you have permissions you can by pass gerrit by pushing directly to master instead of refs/for/master as these changes are already reviewed)
Once all changes are on Gerrits master you do a pull on your master and a merge into feature with rebase making feature a clean branch to work on. It's of course totally valid to have a new feature each release. Both work fine.
I'm a little confused, as this flow should work just fine. If other users submit changes before your bug fix is reviewed/verified/submitted, that could result in merge conflicts, but that should be rare.
If you:
Fix a bug on master
Push to review (creating change A in gerrit)
cherry-pick change A on top of the feature branch (resolving any conflicts from master to feature)
Push the cherry-picked change to review (creating change B)
Review/verify/submit changes A & B
Everything will work fine. The only way for merge conflicts to occur is if other users upload and submit changes between steps 1 and 5. Are you seeing different behavior? Can you provide more details?
Related
The business recently planned to test two separate features in the same sprint, but weren't sure if both of them were going to be deployed. Our solution was to create two feature branches off of Develop, one for each feature, and a third branch off of develop ("the Hybrid Branch") into which those feature branches could be merged. We would only deploy to DEV and QA from the Hybrid Branch, allowing dev and QA to test both features. If one of them was pulled back, the individual feature branch would be merged to develop and deployed without the other.
But we've encountered some strange behavior with one of the feature branches when merging into the hybrid branch.
When creating a pull request, Azure DevOps merges every change from the date that the feature branch was created. It's as if the branch doesn't get rebased properly after a push or merge or what-have-you.
For the other feature branch, it pulls only the set of commits pushed since the last merge. This is how we expect it to work.
This makes reviews of the pull request difficult, as it's difficult to isolate the specific changes for the PR. It also means that resolved conflicts have to be re-resolved for every PR, and the PR acts like previously added or removed files need to be added or removed again.
What could be causing this and how do we resolve it?
I think it's because of squashing. The way git works isn't by tracking a "last merged commit pointer". Every time you merge branches, git looks for any commits that are present on one branch and not present on another. It does it by comparing hashes. So if you merge with squash, then those commits are merged to another branch with different hashes, so the next merge will show them as new commits again.
Regarding one branch working properly, maybe the other branch was rebased to the first? You can check hashes of commits to make sure that they are indeed different on both branches
How do I go about making my pull requests have only the changes made on the new branch? Every time I push a branch it has all the changes from the previous branches included in the pull request also.
My manager is really big on making sure we do small PRs and have only the new changes on each one for easy review, but I'm at a complete loss as to how to do this. This is my first dev job and up until now I unfortunately haven't been able to do group work so managing PRs that might be a while before they are merged in is totally new to me.
So far I've only found how to cherry pick commits, is this the only way?
If I understand you right, you have a main branch (master?) that contains the latest version of your software and you have one or more other branches that contain modifications. You do some more modifications in that other branch and if you create a pull request it will contain all other changes.
The most simple solution I can think of is to use dedicated branches for all changes. Before starting to work, create a new branch from the main branch with the ticket ID, work description or whatever you use to describe your work: git branch -b feature-123.
Commit to this branch only and push it to the repo. If you now create a pull request from this feature branch to the main branch, it will only contain the changes you did and nothing else.
The further pull requests highly depend on your internal workflow and branch structure. But basically this workflow applies to all new changes.
Keeps track of files in eclipse, who made changes on which branch
Hello Guys, I am using BitBucket for project management, and i Create different branches as per features. Multiple teams works on their own branches and some time multiple teams make changes in same file.
So at the time of release I have to merge all the created branches in one major branch, but at time of merge i get a lot of merge conflicts,
So basically what i want, when developer going to make changes in any file, dev will get to know all submitted changes in another branches for this same file, (where dev going to make changes), So he or she will know the possible scenarios.
An alternative is to ask for a developer to rebase his/her own branch on top of the main branch first.
Then you can merge that branch easily enough.
That way:
if there are any conflicts, they are detected and resolve by the developer (who knows best how to resolve it)
each merge is a trivial one.
I am pretty new to Git and I am using sourcetree as a client.
I know that in Git two developers work on the same branch at a time since they have local copies of the remote branch.
So here is a scenario :
A and B are working on a branch feature/release1.0
A commits code to local branch.
Now B commits the code and pushes it to the remote branch as well.
Now A will have to push his changes as well as Pull changes made by B.
So what will A do in this case ?
In this case, A should pull B's changes down first, make sure everything works, commit, and push.
Generally we (my team) don't work quite like that.
When we have two developers working closely on a feature, we work on separate branches and merge into a shared feature branch.
Among the advantages of this is that you can commit and push on your own schedule, which means that you can make your code work without worrying about the other developer's changes and your code makes it to the server quicker. That is, it's somewhere other than your own machine, somewhere that's probably backed up.
A must git pull first (some merge may be needed) and than push the code.
If A try to push his code in the first place, git will tell that the remote and local branches have diverged and instruct the developer to pull the code first.
If you pay attention to git commit error messages (and git status messages) you will always know what to do.
As you said, A has to get the changes from B (git pull) before pushing her changes. It is likely she has to deal with some conflicts, which should be resolved locally before pushing the code.
Apart from that, you should probably reconsider your branch scheme to avoid this kind of conflicts. Would it be possible to work in different branches? For instance, by redefining the tasks, to be more fine-grained.
Moreover, it is weird, at least for me, the name or the branch feature/release-1.0. Looks like there are releases by features basis, os something like that. Take a look at http://nvie.com/posts/a-successful-git-branching-model/. See how the release branches are fed from the developing branch, and this one receives the commits from the features branches.
Hope it helps!
I am new to Perforce and find it really hard to follow its workflow..
I have used Mercurial before (not in any advanced ways), but what I lack most in Perforce is the idea of named branches.
Let me explain what I'd like to do:
I get the latest revisions of all files and want to work on a new feature/story/task..
I create a brach, say "Feature 3021"
I code, save changes in this branch (hg commit)
I can save changes to a central server (hg push)
When I'm done coding, I merge the changes from "Feature 3021" with the main branch (default, master, etc.) - after that the main branch has the code I wrote
I can close the named brach ("Feature 3021") so that further commits are not possible.
I don't need this exact behavior in Perforce, but something analogous. I know that Perforce is centralized, so the commit-push step would be probably one, but this is a minor problem here.
All I care is to be able to save my work in version control at any time, even if it's not 100% ready - perhaps to a different branch. I'd also like other users to be able to be able to get my code (from this different branch), but only if they want this - the default branch should stay unafected as long as I don't merge my changes with it.
Is it possible? I am using Server 2012.2
Can you upgrade to Server 2013.1 or later? There's a great feature there, called Task Streams.
Here's some references:
http://www.perforce.com/blog/130627/task-streams-even-if-you-are-classic-perforce-shop
http://www.perforce.com/blog/130206/task-streams
http://www.perforce.com/perforce/doc.current/manuals/p4v/streams_task.html
The analogous flow in Perforce would be:
Maintain a main-line "branch" at some path, say //depot/default
To create a feature branch, integrate from //depot/default to //depot/feature-3021
Work under //depot/feature-3021 and submit
When you are ready to merge back, integrate //depot/feature-3021 to //depot/default
Regarding closing the branch after its use, there are a couple of options that I can think of. You could either change permissions or simply delete it. The delete could always be recovered.
Also note the paths don't need to be at the same hierarchy. A more reasonable branch strategy might use paths like this.
Main-line: //depot/default
Developer branches: //depot/dev/${user}/${feature}