I created a new branch from trunk( intended as Version 1.1.5.0) and incorrectly named/pointed the branch to an existing branch ( Version 1.1.0.5) in my SVN repository. Can I undo this? I correctly created a new branch from trunk as intended afterwards but now branch 1.1.5.0 and 1.1.0.5 are identical. Would it better to create a new project in eclipse and grab a copy of the production files (which is at Version 1.1.0.5) and commit it to the correct branch? Branch Heirarchy
Related
I was working on a branch of my Bitbucket repo (lets call it "frontend-dev"), which has now been merged with the master branch. I would like to branch again to make further changes, without creating a new branch. How do I branch and get back onto "frontend-dev".
I am using Sourcetree to manage version control.
Normally merging to master does not close or delete the branch. If there are changes in master since the merge from "frontend-dev", you can merge back to "frontend-dev". Either way, you can then simply switch your working copy to "frontend-dev" and continue developing.
Another question discusses what to do when you have closed or deleted the branch: Restore Merged Branch in Bitbucket Repo
I am working on a project with some mates.
Yesterday I cloned the project with the intention to add a functionality.
I have 2 local branches that are develop (the main branch) and pageContent (my feature branch).
The problem I am currently encountering is when I edit something on my feature branch, it automatically edits it on my developp branch too (I did not commit anything).
I checked out on my developp branch to delete the edition and when I checked out on my feature branch, the edition was deleted too ...
The branches seem to be auto-synchronised.
I checked out on my develop branch to delete the edition and when I checked out on my feature branch, the edition was deleted too ...
This is how git works.
In the following diagram you can see the 3 states.
Git has three main states that your files can reside in.
They are all shared between your branches. but when you checkout branch you change the HEAD so you end up with the staging area && working directory shared between your repository even when you checkout branches.
Since you did not commit (i assume that what happened) when you switch branches you see the changes following you to your new branch.
If you don't want the changes to follow you you need to commit (or stash) your work before switching to the branch.
How to checkout different branch with clean working directory and stage area?
If you wish to checkout clean branch without any "leftovers" in your working directory and staging are you can create a new worktree which will result in shared view of your repository (all the content is shared) but with a different working directory and staging area.
From git v2.5
git worktree add <new_path>
Now do whatever you want in any of your branches. It will create 2 separate working folders separated from each other while pointing to the same repository.
Using wortree you don't have to do any clear or reset in order to remove all your staged and untracked content.
Here is demo of how to do it:
In TFS 2013 how can I overwrite all folders and files under a specific folder with data from another branch?
I have a main and two dev branches and different functionality has been added to the same solution in both dev branches. Main is in sync with one dev branch. Now all functionality that has been added to the dev branch which is not in sync is now obsolete and I want to sync the solution in this branch with whats in main. As the solution differs alot between main and the obsolete branch a traditional merge wont work.
Why not just delete the branch (or rename it for archive purposes), and create a new branch off MAIN?
Another option is to rollback all changesets in the Obsolete-Dev branches history, then do a merge from MAIN.
My current employer uses clearcase (I believe Base-CC) for version control. Our project has a branch, and each user has his own branch on top of it. The configspec of the users shows elements from the user branch, then from the project branch, and then from the company-wide branch.
The current modus-operandi, is that the users merge in their changes back to the project branch, and keep working on their own branch.
The problem is, that after the user merges his changes, he still has a branch for this element. Then, when the someone else modifies the project, he still sees his outdated version.
I want the following:
if a user has a checkedout file, display it.
if a user has unmerged worked, display it.
if a user has merged work, show the lastest version from the project
I thought of marking the element branch as obsolete after each merge, but the users still sees it, and not the latest from the project.
Then I thought of changing the config spec, to somehow ignore merged-in branches, but I do not know how to do that.
Any ideas?
You can reuse your personal dev branch, but the correct workflow, when a dev merges his/her branch to the upstream branch (here the project one) is:
first merge the project branch to the personal dev branch
resolve any conflict locally
then merge personal dev to project.
That way:
you don't have to modify the config spec after each merge,
you make sure the merge will be a trivial one,
and the personal dev branch can represent easily the LATEST from the upstream branch after merging (again) the project branch to the personal dev branch: the delta will be minimal.
I am having a major issue with clearcase merge:
I have a list of files taken from clearcase long time back and updated outside clearcase. In between, the same files have changed in clearcase as well. Now, I created a new branch and checked in the updated code from outside in the new branch.
But when I want to merge from new branch to integration branch, it automatically merges and overwrites the changes in integration branch with the changes from new branch. What I would have expected it to atleast raise a conflict and not wipe out the changes made in clearcase integration branch.
can anyone help here please?
You need to be careful from which version you are starting your new branch.
If you are starting a new branch from the LATESt version of the current branch, in order to:
clearfsimport your code modified outside of ClearCase
merge said new branch to your current branch
Then, yes, all changes will overwrite the current versions.
But if you make your branch from an older version (a previous label or UCM baseline), import your code there and merge, then the merge will work or generate conflict if appropriate.
In other words, you need to start your branch from what you estimate is a common ancestor for your merge to work.
See "Rebasing and merging in ClearCase":
.