When I create a feature, I create a branch from develop. Then when the functionality is finished, I merge it to develop but there are many conflicts because develop has been updated with other functionalities.
What my team has recommended to me is to constantly update develop and immediately merged to the feature I'm developing.
That way I wouldn't have as many conflicts when I merge the feature when it's done.
My questions are:
This way of working is still Gitflow? or is it a variant of it?
If this way of working is not gitflow, does it have any other name?
What happens if there is a bug in develop and my feature inherits
it?
Best regards.
It depends on how you merge the branches (with git merge <branch-name> or with git flow feature start <branch-name> and then for merging with git flow feature finish <branch-name>). If you do it like the second approach, it's git-flow, otherwise it's just "normal" git.
I would first create a git flow branch from the develop branch (git flow feature start <branch-name>) and then make the changes there. Everytime you want to push changes, you do git push (the first time it has to be git-flow feature publish <branch-name>!!!) Then all changes are visible on the git server under the branch name feature/.
If you want to merge the feature branch and the develop branch, just do git flow feature publish <branch-name>.
How to resolve merge conflicts
There are lots of tools that can help you do this. As you may have already guessed, I’m most comfortable with using a text editor. It just seems to be clearer and I’m less fearful of doing something accidentally by clicking on a UI button. Find the file and then make the changes.
Generic steps for any file:
Find <<<<<HEAD. Look for ======
Everything between HEAD and === is what you have in your code.
Everything between === and >>>>develop is what the develop branch has.
Figure out what you want to keep and then delete <<<<HEAD, ==== and >>>> develop.
If it is a bug in the feature branch where merged in develop branch, so the bug is in the develop branch too, except the bug gives a merge conflict (because there is different code at this point) that you have to edit manually.
Related
We have three developers working on a microsoft visual studio project that is being hosted on Github but we are using the VS Github extension tool.
We are a little confused about how many branches are necessary for our project.... This is what we have right now.
Master Branch -> Development Branch.
The idea that we are currently working with, is that we will each individually make changes, and then push up to the Development Branch to test with. When Coder 1 makes a change, Coder 2 and 3 will see the change and can merge their projects with the Dev branch and vice versa- so we stay in sync.... Then when we are comfortable with the changes, we merge Development Branch into Master Branch.
We are wondering if we need more branches, or if more branches would be userful....
For example what if we had:
Master Branch -> Development Branch -> Coder1 Branch, Coder2 Branch, Coder3 Branch.
Is there any benefit to adding more branches? We only have three coders and are wondering what the setup should look like.
Thanks!
With only three programmers, I believe everyone can work on the development branch at the same time as long as there's proper communication on what parts each are working on. Everyone can work on the development branch and when it's time to push their own changes, I advise:
git stash, which will put your changes into a temporary stash and revert back to HEAD, pretending like you did not change anything
git pull, which will pull the others' changes
git stash pop, which will bring back your own changes. This way, you can build "on top" of other people's changes. If there's a merge conflict, "local" will be the other person's changes and "remote" will be your own changes.
But if you really want to be safe and formal, separate branches for each person can work, and using GitHub's page, it's easy to implement a pull request and do code review.
All in all, it just depends on how formal you want it to be.
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.
We're using Mercurial to manage a project that has two teams working on it. Our team manages the repo, and we're using hg flow on it, with default, develop and feature branches. The other team does their work in a separate repo, with us pulling in their changes every now and then.
The other team isn't particularly up to speed on Mercurial, and they've wanted to do their work on the default branch. This makes pulling in their changes annoying, because we'd like to keep our default branch clean.
We've done what Ned Batchelder suggested in http://nedbatchelder.com/blog/201111/advanced_mercurial_branches.html, but that still leaves commits in our repo with their branch marked as default. So does using Bitbucket's pull requests.
Other options that spring to mind are using patches or using graft and strip. I'd love to hear suggestions that would be less hassle.
If you want "Hard way, but nice results" you have to forget about easy pure-Bitbucket interface of syncing repositories
With Convert Extension --branchmap option you can rename any branch in source repository into any name. Thus, your workflow will be something like:
Prepare file for branch-mapping
Clone|pull from fork to local repository
Convert cloned repo, using branchmap, into repository with good naming of branch(es)
Push result of convert into your Bitbucket0repository
Or consider using bookmarks instead of named branches. Then you can move their changesets into your develop bookmark without any of its past default-ness showing through.
hey're not entirely crazy for wanting to develop in the default branch; it's the standard advice: https://www.mercurial-scm.org/wiki/StandardBranching#Don.27t_use_a_name_other_than_default_for_your_main_development_branch
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?
We have team of 10 developers who works parallel for different features, sometimes these features use common code sometime no.
And now we're changing our process to branch-per-feature and it seems mercurial is more suitable for such development.
I see this process so:
1. make release branch (r-b) from default(trunk)
2. make feature branch (f-b) from default(trunk)
When developer thinks his feature is done he can merge f-b to r-b. When it's time to go to QA we merge all finished f-b to r-b and create release for our QAs.
Questions:
When QA finds a bug developer should modify his f-b and merge it again to r-b. Does it mean that developer just switch to his f-b and start fixing the bug and then makes simple merge f-b to r-b again?
When release is passed QA it goes to PROD - how can we freeze changes? "hg tag" is good choice but someone can update tag if he really wants it.
Thanks
If you're going to merging into specific release branches then your feature branches should be branched from the release branch, not the trunk. It is simpler to merge with the parent branch than a non-parent branch.
1) If you really want to do feature branches then each bug would have its own branch. This will help keep bug fixes separate from new features. After all, it's branch-per-feature not branch-per-developer.
2) Hg tag is what I have used. You are right that someone change move a tag if they really want to, but tags are versioned and you can install hooks on the main hg repo to throw alerts if a tag is moved. I really wouldn't worry about tags being moved unless you can't trust your developers, in which case you are screwed.
The answer to your first question is 'yes'.
The best way to freeze for release is to have a separate release clone that only the release manager can push/pull changesets to. Just because you're using branches doesn't mean multiple-clones don't have a place in your workflow. Have a clone that QA does final pre-flight testing on to which developers can't push changes makes for a great firewall.
Also, consider using bookmarks for your feature branches. Since, as I'm sure you know, Mercurial named branch names never go away the git-like bookmarks work well for sort lived concepts like features and bugs.