I kind of feel I am missing something here, but here is the question.
I have a branch A. Work is in progress in this branch. A tag T is created which marks a production release version. Now, a fix has to be done on top of the code in this tag. So I created a branch B out of the tag. The branch would contain stable production code.
My eclipse points to checked-out code in branch A.
Now, I want to make changes to code in branch B. How can I make my eclipse realize that there are 2 different branches and the code is different?
Do I have to clone the branch B and point a new eclipse workspace to it?
Cant I use the same workspace and have 2 different versions of the same file - one from branch A and another from Branch B?
Just checkout branch B in your workspace, make your changes, commit, and then you can checkout again branch A and continue to work on branch A. Eclipse will automatically recognize the content of the other branch
However, you should be aware, that you shouldn't have uncommitted changes in your workspace, when you checkout another branch. Either commit your changes or stash, before checkout.
assuming you have eclipse integrated with your git system, you can use select the project you are working on, and then in the context menu, use "Team->Switch To->New Branch...", and choose branch B.
if you don't have it integrated, you can do so with the following 2 steps.
using the git perspective, in the Git Repositories view, find the icon with the + to perform Add an existing local Git Repository to this view .
in the subsequent dialog, choose the location of your repository.
once it's added, go back to your java perspective, and from there, select the project in git (which you currently have in branch A), and from the context menu, select Team->Share Project
Related
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:
Using tfs2015 (not git but tfvc)
We have a MAIN branch and I created my development branch from MAIN branch.
__MAIN (branch)
|__MYDEV (my new branch)
After a while, my friends pushed 2 new changesets to MAIN.
__MAIN [change1], [change2]
|__MYDEV [mychange1]
Question: How can I get those 2 changesets onto MYDEV branch as 2 changesets as they are by merging (rebasing) my change on their changes?
If I try merging MAIN onto MYDEV, 2 changesets are coming as pending changes of bunch of files, but I want them as they are as packaged in 2 changesets and put my changes on them.
Finally what I expect,
__MAIN [change1], [change2]
|__MYDEV [change1], [change2], [mychange1-with-merge-fixes]
If you use git-tfs it will give you all the powers of git, highly recommended. Now, visual studio will maybe be a little bit upset when it detects a .git directory, but you can avoid that by setting GIT_DIR and GIT_WORK_TREE environmental variables (see this answer for details).
You can use "Rebase" tool to keep every merged changeset separately in the branch.
To use rebase tool in TFS, follow the steps below if you have Team Explorer installed:
Launch Team Explorer and connect to your project.
Open "Branches".
Checkout the branch (MYDEV) you'd like to rebase.
Right click the branch and select "Rebase Onto..." option.
Select the Onto Branch (MAIN) and then click "Rebase" button. (Resolve the conflict and click "Continue" button if there is any conflict during the rebasing)
Introduction about TFS Rebase: https://msdn.microsoft.com/en-us/Library/vs/alm/Code/git/rebase
I have Branch A and Branch B in the local branch folder.
Branch A is under working.
Now I want to switch to B.
The window pops out:
Checkout Conflicts
The files shown below have uncommitted changes which would be lost by checking out 'master'.
Either commit the changes, stash the changes, or discard the changes by resetting the current branch.
project.properties.
There are 3 options:
Commit..
Stash...
Reset
No matter which option I choose, it does not work.
For example, if I choose "Stash" option, it says:
"The repository does not contain any local changes to stash".
I suspect the egit records have some conflicts, so it cannot know how to do the next step.
The only way:
To remove the local branches, and clone the remote repository to the local?
This needs cost some time for downloading.
I had the same problem. EGit complaint about .class files which were not commited. I deleted the .class files and was able to switch to the desired branch without problems.
IMO removing local branch is not required.
I suggest first to pull the remote changes to local Branch A.
Resolve any conflicts while pulling the changes if any. Refer this video
Add your changes to Git staging area just by dragging the the files from unstaged area to staged area refer pic below.
Click on commit button, then push the changed to remote branch.
After doing this Branch A will be clean, then you can switch to Branch B just by double clicking on it or by right clicking on the repository node and selecting Switch to option in Git repository view.
Also I suggest to use the latest stable Egit plugin from here
I have an SVN branch and a trunk. The trunk changes regularly and the branch doesn't.
Every now and then (let's say once per week) I want to update the local working copy of the branch with the latest changes of the trunk.
Ideally I would want to do this the same way as I do it with the latest version of the branch: with Eclipse : Team->Synchronize, so I can review all changes before updating.
Is this also possible with a different repository (for example : trunk) ?
If not, how do people review the changes before updating then??
I looked at Team->Merge, but this seems to update the changes directly to my working copy, without the possibility to review the changes first (the Preview-function is confusing, I think, and doesn't provide the nice side-by-side view of changes/conflicts that Synchronize has).
The right way to do this is with Merge. Subclipse includes a merge client that makes this easy to do. You are right that it does not give you a true preview, but the way it works is better from a Subversion perspective. The Merge Results view UI is basically the same as the Synchronize view. It lets you easily examine every change that the merge made in your working copy and the Eclipse compare editor that it opens makes it very easy to take out any parts of the change that you do not want in your code before you commit.
The problem with trying to do this from the Synchronize view is that you are then doing the merge yourself using code editors and Subversion has no awareness of what is merged. If you let Subversion first do the merge, then it can update all of its metadata properly and it is perfectly fine for you to then fixup the code to be the way you want it before you commit the results of the merge.
I'd checkout both branch and trunk as a separate eclipse projects into workspace. Then use some merging tool, for example meld to merge changes between them. After merge you can refresh branch in Eclipse and synchronize it with svn repository - now you can review all changes. (it's how I do it, since I do not believe svn eclipse plugin ;))
I agree that it is not really intuitive by design, but Mark is right, you "synchronize" your changes when committing them back to the trunk:
first make sure your local branch is completely synchronized with your repository branch (no changes)
Team -> Merge... your local copy of the branch with the repository trunk
you now have a local version of that merge
you can locally edit this version, make sure tests are working and there are no compiler errors
finally you synchronize your local merged branch version with the repository branch and commit all changes that have been made
besides, the same way you'll merge your branch back into the repository trunk
make sure all changes of your branch are committed to the repository branch
switch to the trunk Team -> Switch...
merge your trunk with your branch Team -> Merge... (Tab 'Reintegrate')
you now have a local version of the merge, you may edit the changes and review them, make sure that you have a working version now
synchronize your local trunk (merged version) with the repository trunk
commit all changes that you want to appear in the trunk
i recommend to commit all changes that you've made locally to your merge, since you've tested them locally. if you commit just a few changes, make sure the repository version is still working then with missing changes
I'm just starting working with Mercurial and Tortoise HG. I've created two uncoupled changes, one is a bug fix and one is a new experimental feature.
What is the best way to set this up (using bookmarks, tags or branches or something else) so that I can commit both but push only one of the groups of changesets to the remote repository.
And can this be done easily in Tortoise HG or is command line knowledge of mercurial required?
You can do this from both the CLI and from TortoiseHg. Note that using bookmarks, tag, etc.. has no influence on what you can push.
Using TortoiseHg v1.X.X
Identify the outgoing changesets and then right-click on the head of the branch you'd like to push and select push this branch.
Using TortoiseHg v2.X.X
You must first configure the tool to allow pushing new named branches by clicking Options and selecting the following:
Using the Target option in the Synchronize view, select the branch you want to share and perform the push. This will only share the selected branch. Unchecking Target will cause every new changeset to be pushed.