I have a java project that used to deal with a remote repository that now doesn't exist any more. It has a history I'd like to keep and I need to create another remote bare repository where push to and pull from, for the future commits. How can I do this, just starting from the only copy I have now, the local one (which is already some commits ahead)?
Eclipse has a Git Perspective that helps you achieve this.
Head over to Window -> Open Perspective -> Other and choose Git from the dialog
You would be presented with the Git Repository view.
Expand the Remotes section, and Click on Create Remote... Fill in the details of your new repository.
You can then choose to remove the previous remote and rename the newly created one as origin.
Related
I have uploaded my project on github using intellij IDE but I need to know how to update the uploaded repository on github when I add new code ?
"Adding new code" into your Git repository (your local repository, at first) is made by "making a commit". Full details about this : https://git-scm.com/docs/git-commit
Then, after one or more commits, if you want to upload your changes to your remote repository (the one at GitHub), you'll have to "push" your changes : https://git-scm.com/docs/git-push
For details and examples on using Git (because this goes far beyond a Q&A site thread), please have a look at my Git beginner's guide
The question does not look IntelliJ-specific.
To update the code on GitHub you need to commit changes to your local git repository and push the changes to GitHub. See https://help.github.com/en/articles/pushing-to-a-remote
Check the docs to see how exactly one commits and pushes in IntelliJ.
https://www.jetbrains.com/help/idea/commit-and-push-changes.html
I can view local history of a single file with History View. But I need to see local changes for projects. I found that for remote changes. I need the same thing but for local changes.
if you are connected to a repository then it must be simple, please follow the following steps.
Right click on the project-->select team-->select show history.
This should do it.
If you don't have one then(pretty sure its not possible for entire project) you must consider getting one, i personally think github is useful
When I right click on any working set(In package,Navigator etc view) I am not getting synchronization option under Team Menu. See Picture below. Note that all projects in this working set are present in the git repository.
Is there any way to synchronize single or multiple(group of i.e working set) projects with git repository without switching to synchronization view?
See the open EGit bug 311299 for making the Team menu work on Working Sets (contributions welcome!).
For launching synchronization for a repository, it's enough to select one of the projects and selecting Team > Synchronize Workspace.
I have a new class being pulled from my remote git repository (this class does not exist locally at the moment), as shown in the image above.
In the team synchronizing view in eclipse when I right click on the class I am given the following options (see image below) and I'm not sure what to do.
I know with svn you have an update option, but this isn't available here, is merge the correct option?
Yes 'Merge' should be able to pull the class from remote.
Assume I have a class.
package org.my.domain;
public class BestClassEver{}
My Workflow
Through some refactoring, I change this class's package.
package org.another.domain;
public class BestClassEver{}
I commit this to my local repository using git and push it to a remote repository.
git add .
git commit -m "Refactoring"
git push origin master
Another Developer's Workflow
Another developer modifies the class, without pulling my changes.
package org.my.domain;
public class BestClassEver{
private String something;
}
Then commits and pushes to the remote repository
git add .
git commit -m "Some Changes"
git push origin master
Questions
Will Git merge the other developer's changes into the class?
If not, what happens?
Is this workflow something that needs to be coordinated amongst the team?
Git won't allow the other developer to push his changes without pulling.
It will throw an error that both refs don't match and therefore his local branch needs to be updated with the remote refs.
That's pretty much all there is to know about that. If there are changes in the remote repository, unless you do a forced push, git won't allow you to push changes if there are changes in the remote.
EDIT
Once he pulls, if there are any conflicts in the file, the developer will have to correct any conflicts, commit them and only then he will be able to push.
If there are no conflicts, git will automatically merge those changes and the developer will be able to push after the pull.
EDIT AGAIN
I didn't realize that you were moving the file. In any case, running git status would give you an idea as to the state of your local repository after a pull. If there was any conflicts, you'd be able to correct them.
NOTE
On git rebase or git pull --rebase are usually used to give you a much cleaner commit history as they will pretty much will apply any local changes on top of any other changes that were pulled.
On the other hand, git pull and git merge will usually make an extra commit to link the changes on the branches.
For more information take a look at this guide Git Rebasing
It is always good idea to let people work on different parts of program.
Merge or rebase in this case should be fully automatic, but in real world it is always a bit dramatic and sometimes there are some conflicts. Of course, this merge/rebase will be done after server rejects push for beeing non-fast-forward.
When such thing fails, some workarounds include:
Just repeating "refactoring" in the other branch prior to merging;
Converting the work to patch (git format-patch), editing the patch (applying that "refactor" to it) and applying the edited patch (git am). It is like manual rebasing.
I think it's better to separate merge-complicating refactoring (one that involves renaming, for example) and usual minor refactoing.
Sometimes for a merge-complicating refactoing a script can be written (such as find -name '*.c' -exec sed 's/something/anything/g' -i '{}' ';'). The script be used to repeat the refactoring multiple times in various places when we need it, so avoiding to merge refactored code with non-refactored one.
YES. Git is able to identify those changes. I am working on a project using git on my own fork (forked from origin). In the meantime another developer refactored the codebase on the original fork, which includes changing package structure.
I used the following commands:
git stash save // this saves all your work onto a personal stash
git pull // fetches all the latest changes on the primary fork and merges
git stash apply stash#{0} // or whatever the stash is where you saved your personal work
Now you will have the refactored codebase+your changes. You can now commit without any conflict and the packaging will not be changed.
Just note that in my case I waited for the original fork to be refactored and then I committed my changes, which are only changes to few files and not repackaging.
Also note that if you have added new files, then you might have to edit a few imports to make sure the imports are correct.
eg. import org.my.domain;
should now be edited to: import org.another.domain;