I have looked all over for a way to force a rebase when merging in TFS. I am looking for a way to force developers to get latest of the parent branch and merge it down into their own branch before merging back up to the parent. Most results now are coming back with GIT articles but we are using TFVC.
There is no out-of-tge-box way to 'force' developers to do this.
Professional developers should always make sure they have an up to date workspace and have completed a build and run unit tests before checkin in. This is a discipline issue.
You could create a checkin policy that checks for this. But that would be over kill.
..
Related
Caveat: I am fairly new to both git and GitHub.
So, in my current setup, my team uses git flow Hotfixes (usually started and finished by a graphical tool such as GitKraken or IntelliJ) to make changes that have to be merged into two branches and pushed upstream in both. So for example the flow would be:
Pull latest from master
Start hotfix
Commit changes
Merge hotfix branch into both master and develop and push both upstream
We're now looking at moving our code into GitHub and would like to start using Pull Requests, for a couple of reasons:
CI hooks to run tests and stuff
a place to put code-specific comments not directly related to the underlying "issue"
avoiding the need for everyone to constantly be pulling the latest master/develop to their local machine so that they can merge changes
But in the case of Hotfixes, I'm not sure what to do because I'm merging into two branches but it really is one "action" so manually creating two pull requests seems weird, particularly since step 4) in our current flow is a single click.
Is there a smart way of handling this? My ideal case would be that pushing the Merge button on the Pull Request would just merge into both, but that doesn't seem to be an available option.
As you mentioned, a Pull Request has only one target branch, so you won't be able to push the hotfix to both master and develop by merging one Pull Request.
I'm also surprised you mention your step #4 - merging the hotfix branch to both master and develop and push upstream - is one action. While there's a high chance the merge from hotfix to master won't run into merge conflicts, I can't say the same for the merge from hotfix to develop since it could have been worked on since the last deployment to production.
My recommendation would then be the following:
Create one PR from hotfix to master and have someone review it to validate the fix
Once it's merged into master, create another PR from hotfix to develop and see if you run into merge conflicts
If that's the case, resolve the merge conflicts so the PR ends up in a state to be merged, and have someone review the PR
If there's no merge conflicts, then have someone review the PR
An alternative solution, if you really want to go down the automated path, would be to leverage both GitHub webhooks and API.
The webhook would allow you to be notified when a PR is merged. You could inspect the payload to make sure that the base branch starts with hotfix/ and the target branch is master. You could then react to that event by using the API to create a new PR from the same hotfix branch to develop.
It will involve some development, and the effort might not be worth since creating a PR via the UI is still quite easy and quick.
My development team recently doubled in size from one (myself) to two. As the sole developer, I was maintaining the trunk as the stable version of our software. I'd make changes in my working copy, test, and only push to trunk once I was sure it was stable.
With the new team member we are trying to come up with the best flow for co-developing the codebase. We have decided that trunk will stay stable; changes are pushed there only after code review and thorough testing. The teammate will create feature branches for features he works on; when he requests a code review, I will do it and then once approved, he will merge the branch into trunk and delete the branch.
We are both using eclipse and the subclipse plugin to manage our working copies.
The problem is that while I can view differences between my working copy and his branch (Team -> Compare To -> Branch), I do not know how to get the code from his branch to merge with my working copy. I want to be able to get his changes without losing any local changes I have made, run his code locally, and have none of this affect trunk. That seems to rule out the option in Eclipse/SVN to switch to another branch/tag/revision, since I need to have his code merged with mine (in order to make sure my working copy's code is consistent with my local database).
We've looked at the SVN Patch feature, instead of using branches perhaps he should send his changes over through a patch which I run?
So the concrete question here is: how do I merge/incorporate changes from a branch with my working copy without touching trunk? I would also be grateful to get suggestions on how we should implement our workflow in a way that takes advantage of the power of svn and eclipse in a way I am missing.
Both of you should have checkouts of trunk and any branches you're both working on. When he is ready to have his branch merged into trunk, you should:
Ensure that his branch builds successfully.
Ensure that your trunk checkout is pristine (no SVN added, modified, deleted, unversioned or ignored files).
Conduct the merge, resolving any conflicts with his help.
Perform a code review, including ensuring that trunk is stable with his changes.
Commit the merge.
Conduct the merge outside of Eclipse, using the SVN command-line. I've seen enough questions here on SO related to Eclipse and Subclipse that tells me the plugin is unreliable.
If it was me managing this workflow, I'd have two checkouts of trunk: one which is meant for merging and is always in a pristine condition, and another in which I can actively develop. That way, I wouldn't need to create a patch of my changes, then merge, then apply the patch.
Hope this helps.
The sad truth is that SVN will probably not be fit for this pattern. Branching creates a lot of pain in Subversion
Check here to get more details.
It was enough for me to update the branch from command line with 'svn up'.
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've been using source control systems for about 10 years, each obviously with their own idioms and practises.
I am currently using Mercurial for .NET development and have a particular requirement that I wonder what your opinions would be to best achieve my goal.
We develop a baseline product that is a kind of rolling release. Some customers need the product slimmed down (due to getting cheaper licenses) or bespoke work done. I tend to branch the "trunk" (default branch in Mercurial), do the bespoke work and create a build.
When new work is done in "trunk" and I need a new build from the bespoke branch, I will merge the changes using hg merge -r CHANGESET_NUM_FROM_DEFAULT_HERE and then do a build.
This works fine, but the bespoke branch quickly gets filled with commits that are related to "trunk" and not really bespoking features. This means when I need to look through the changesets for this branch they are cluttered.
What I really want it to shift where the branch "junction point" begins, so the bespoke changelist only contains bespoke check-ins, but the parent of the bespoke branch changes.
I tried to use the rebase extension as this looks like it should do this, but it instead does many merges and still clutters up my bespoke branch.
Is there a way of keeping my bespoke branch clean? Or am I going about things the wrong way?
Your bespoke branch is clean now. But - if you want don't see mergesets in branch log, just skip in log
hg help log
options:
...
-M --no-merges do not show merges
hg log -r 55:tip --template "{branch}:{rev}\n" -b default
default:55
default:56
default:57
default:60
default:61
default:63
default:65
default:66
hg log -r 55:tip --template "{branch}:{rev}\n" -b default -M
default:55
default:56
default:57
default:61
default:65
default:66
and screenshot of graph from THG
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.