We Keep Coding

Merging local branch into modified original branch

I have forked original repository into my github account and cloned the same into my workspace. After working for a week on my local branch I want to push my local branch to my forked repository and then merge it with original repository. But I can see that files that I have modified in my local branch have also been modified in the original repository. I can think of two approaches for merging my local branch safely.
Should I first get the latest changes from the original repository into my local branch using git pull? In this case will the complete file be overridden or only parts of the file that has changed in the original repository preserving my local changes.
Second approach is to go ahead with pushing my changes to my forked repository and then merge it with original repository. Here I am assuming that Git considers a conflict only if there are two different versions of the same line in a file. In case the two versions of the file have changes in different parts of the file they can be merged safely.
I am also little unclear about when Git merges two versions of a file. How does it decide which version of the file will take precedence over the other.
Any other approach to do the same is welcome.

First of all, in such scenario it is hard to avoid conflicts at all, and generally working on the same repository with other people you should be prepared to resolve conflicts once in a while.
In your case I would use git rebase and utilize git branches, which are a really useful feature when used well.
Create separate branch with your changes locally
Revert your local master branch to the state before this changes
Update local master branch with changes from the original repository
Push your master branch to your remote repository (so that your forked version matches the original repository)
Rebase your local feature branch onto master. In this step you'll probably need to resolve some conflicts. But it would be easier, as you are based on current master (destination of your changes), and you are in control what should go in, and what should not. Also, you can easily test your solution after rebase, and make some changes before issueing a pull request.
Push local feature branch with your changes to your remote repository.
Create pull request to the original repository.
// I assume that your local master branch is set up to track origin/master branch, where origin is your forked version of the original repository.
// 1. Local branch named "my-new-feature"
$ git branch my-new-feature
// 2. Reset your master branch back to the state before changes
$ git fetch origin
$ git reset --hard origin/master
// 3. Update local master branch. First you need to add the original repository as a remote (let's name it "upstream")
$ git remote add upstream https://github.com/some-user/some-project.git
$ git fetch upstream
// you should still be on your local master branch. Now update this local branch with changes from the original repo
$ git rebase upstream/master
// 4. Push your local master to your forked repository
$ git push origin master
// 5. Rebase your changes onto master
$ git checkout my-new-feature
$ git rebase master
// This is the place where you are most likely to have conficts. Read git messages, as it helps you what to do.
// Once all conflicts have been resolved, stage your changes but do not commit. If committed they will not be detected by ongoing rebase.
$ git add .
$ git rebase --continue
// 6. Push your local branch with newest changes
$ git push origin my-new-feature
// 7. Issue a pull request on GitHub using your just pushed branch
Also, git merges two files based on the direction of the merge. If you are on a branch A-branch, and you run git merge B-branch, then files from B-branch have "higher priority" and their changes will be most likely applied automatically.

I will suggest the first approch as you listed: pull the changes from the original repo first. Reasons as below:
It will save energies for the users who view pull request and merge the branches.
If there has conflicts for mering the pull request, you should also resolve the conflicts again in your local repo, and then push to the fork repo again.
Pull changes from the original repo only overwrite parts of files not all files. Situations as below:
Files neither changed in original repo nor your local repo: these files won’t changed.
Files changed in the original repo but not changed in your local repo: these files will be overwrited as the version of the original repo in your local repo.
Files not changed in original repo but changed in your local repo: these files won’t be overwrite.
File both changed in original repo and in your local repo: these files will show as conflicts, you should resolve the conflicts manually.
To pull the changes from original repo, you’d better pull with --rebase option (pull the change from original repo first, then apply your local changes on the top of the latest original repo:
git pull <remote> <branch> --rebase
Assume the commit histroy as below after git fetch (origin is the remote for the fork repo, upstream is the remote for the original repo):
…---A---B---C---D---E master, origin/master
\
F---G---H upstream/master
Then you can execute below commands:
git pull upstream master --rebase
git push origin master -f
Then the commit history will be:
…---A---B---F---G---H---C'---D'---F' master, origin/master
|
upstream/master
Then you can create a PR to merge the fork repo master branch into the original repo. It will be convenient for PR viewers and approvers.

How to delete local and remote repositories in bitbucket using command line in windows OS?

I am trying delete local and remote repositories in bitbucket using git bash.
I am able to delete my local repository using .git directory in myroot-directory of my repository, but
git remote rm repositoryURL
used to delete remote report but i could not.
Can you please help me
Thanks

You've got a few problems here.
git remote rm repositoryURL
used to delete remote report but i could not.
First, git remote rm is used with the name of the remote, not its URL. You'd have to do something like git remote rm origin.
This updated command won't work because you have already deleted .git/, so you no longer have a local repository. git remote requires a local repository.
But even if you'd run git remote rm before deleting .git/ it wouldn't remove the repository on Bitbucket. The documentation says that git remote rm <name>
Remove the remote named <name>. All remote-tracking branches and configuration settings for the remote are removed.
This simply configures your local copy to forget everything it knows about the remote. The repo on Bitbucket will still exist, e.g., you could clone it again.
To actually remove the repository from Bitbucket you have to log into its web interface and do it there (or possibly use the API).

How Do I Upload Eclipse Projects to GitHub?

I have code in Eclipse that I'd like to upload to GitHub but so far I can't figure out how. It says "create a repository" but that looks more like a folder that holds your projects and I'm not sure how to upload my code to it. Apologies for the seemingly dumb question. Also, how does one delete repositories? Didn't see a way to do that either.

While the EGit plugin for Eclipse is a good option, an even better one would be to learn to use git bash -- i.e., git from the command line. It isn't terribly difficult to learn the very basics of git, and it is often very beneficial to understand some basic operations before relying on a GUI to do it for you. But to answer your question:
First things first, download git from http://git-scm.com/. Then go to http://github.com/ and create an account and repository.
On your machine, first you will need to navigate to the project folder using git bash. When you get there you do:
git init
which initiates a new git repository in that directory.
When you've done that, you need to register that new repo with a remote (where you'll upload -- push -- your files to), which in this case will be github. This assumes you have already created a github repository. You'll get the correct URL from your repo in GitHub.
git remote add origin https://github.com/[username]/[reponame].git
You need to add you existing files to your local commit:
git add . # this adds all the files
Then you need to make an initial commit, so you do:
git commit -a -m "Initial commit" # this stages your files locally for commit.
# they haven't actually been pushed yet
Now you've created a commit in your local repo, but not in the remote one. To put it on the remote, you do the second line you posted:
git push -u origin --all

Here is a step by step video of uploading eclipse projects to github
https://www.youtube.com/watch?v=BH4OqYHoHC0
Adding the Steps here.
Right click on your eclipse project -> Team -> Share project
Choose git from the list shown; check the box asking create or use repository -> click on create repository and click finish. - This will create a local git repo. (Assuming you already have git installed )
Right click on project -> Team -> Commit - Select only the files you want to commit and click on Commit. - Now the files are committed to your local repo.
Go to git repositories view in eclipse ( or Team -> Show in repositories View)
Expand the git repo of your project and Right click on Remotes -> Create Remote
Remote name will appear as origin, select 'Configure Push' Option and click ok
In the next dialog, click on change next to URI textbox and give your git url, username, password and click on 'Save and Push'. This configures git Push.
For configuring Fetch, go to Git Repositories -> Remote -> Configure Fetch -> Add -> Master Branch -> Next -> Finish -> Save and Fetch
For configuring Master Branch, Branch -> Local -> Master Branch -> Right click and configure branch -> Remote: origin and Upstream Branch : refs/heads/master -> click ok
On refreshing your repo, you will be able to see the files you committed and you can do push and pull from repo.

You need a git client to upload your project to git servers. For eclipse EGIT is a nice plugin to use GIT.
to learn the basic of git , see here // i think you should have the basic first

For eclipse i think EGIT is the best option.
This guide http://rogerdudler.github.io/git-guide/index.html will help you understand git quick.

Many of these answers mention how to share the project on Git, which is easy, you just share the code on git, but one thing to take note of is that there is no apparent "project file" that the end user can double click on. Instead you have to use Import->General->Existing project and select the whole folder

Jokab's answer helped me a lot but in my case I could not push to github until I logged in my github account to my git bash so i ran the following commands
git config credential.helper store
then
git push http://github.com/[user name]/[repo name].git
After the second command a GUI window appeared, I provided my login credentials and it worked for me.

Using git to put a project into a repository

I have a new project in Eclipse in the directory ProjectDirectory which contains the src, lib, etc. folders. Note that this project has never before communicated with any repository.
I have a git repository https://github.com/myrepo/mygit.git with a username user and a password pass (note that this is fake info). In that repository, I currently have some files.
I want to do the following.
Remove ALL the current contents in the git repository
Add the new contents from my Eclipse project into this repository. This should result in no conflicts or no errors whatsoever, since I want to completely replace the current repository with these files.
With specific instructions, what set of commands in the terminal would I write to accomplish this?

Its fully simple. First go into the directory in terminal where the eclipse project is.
To start putting this under version managment:
git init
Then add the origin as the git repo ( copy your ssh read+write access from github, this you see when you are loggin in on github and navigates to the actual repositorys directory ):
git remote add origin <copied_adress_from_github>
So now in the last step you will need to overwrite forced the remote repo with:
git push -f origin master
You can start commiting, making branches etc... However if on the remote repo there was other branches you want to remove them with:
git push origin --delete <branch_name>

Most robust way to convert a CVS repository containing Eclipse projects to git?

I have a situation where I have an elderly CVS repository which we would like to convert to git once and for all while keeping full history etc.
All folders at the root of the repository contains Eclipse projects (either plain or dynamic web projects) including .classpath and .project. We use Team ProjectSets to check out the projects we need for a given task (where the project set is located in the project containing the main, and the rest are library projects).
When the Team ProjectSet is checked out, the workspace is fully populated.
This approach has worked pretty well for many years (except the project set part which came with 3.5), and we would like to work in a similar way with git if possible, but we are uncertain how.
I've played somewhat with git cvs import but it failed - probably due to us not using modules.
How would you suggest we do this, and how should we work with git to allow our current usage of shared library projects? Would we HAVE to introduce maven and create maven modules for our library projects? Or just ant ivy?
EDIT: I've now managed to convert our CVS repository to Subversion with a suitable cvs2svn invocation and found that Eclipse recognizes the resulting Subversion repository nicely. Unfortunately after cloning http://github.com/iteman/svn2git` and trying to run bin/svn2git I get
tra#Sandbox:~/cvsgit/svn2git/svn2git$ bin/svn2git
bin/svn2git:35:in `initialize': wrong number of arguments (2 for 1) (ArgumentError)
from bin/svn2git:35:in `new'
from bin/svn2git:35
This is with Ubuntu 10.04.1 LTS Server and I've tried various sudo things with Ruby and its gems without fully understanding what I did as I am not a Ruby programmer so I may have messed up things a bit. I'd appreciate advice - if the easiest is to install another Linux variant to do the conversion, that is fine.
EDIT:
https://help.ubuntu.com/community/Git
http://css.dzone.com/articles/subversion-git-morning
Edit: My first try with the default svn2git completed successfully (after a while), and I get a nice repository where git branch -a reports roughly
tra#Sandbox:~/gitroot/svnroot$ git branch -a
* master
remotes/XX64_DEPLOYED_CODE
remotes/Beta1
remotes/Beta2
remotes/SV46
... lots more
We are interested in being able to check out the SV46 branch and work with it (we basically do not care about the tags, just actual branches). I have set up gitosis and pushed this repository to gitosis, and cloned it to another computer to find out how to do the "work with SV46" bit with Eclipse. THAT repository does not know of all the branches:
tra#TRA ~/git/git00 (master)
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
Do I need to massage the original result from svn2git to get the information into the gitosis repository? Do I need to clone with an argument? Should I redo the svn2git step with the suggested version instead of the one shipping with Ubuntu?
EDIT: It turned out that publishing the svn2git generated repository with "git push --mirror" made things shown up in the gitosis repository. I now see the following inside gitosis (trimmed):
tra#Sandbox:/srv/gitosis/repositories/git01.git$ git branch -a
* master
remotes/XX64_DEPLOYED_CODE
remotes/Basic_Beta1
remotes/Beta1
remotes/Beta2
remotes/SV46
... lots more
tra#Sandbox:/srv/gitosis/repositories/git01.git$ git branch
* master
tra#Sandbox:/srv/gitosis/repositories/git01.git$ git tag -l
tra#Sandbox:/srv/gitosis/repositories/git01.git$
Trying to clone this repository with git clone gitosis#sandbox:git01 -b remotes/SV46 or git clone gitosis#sandbox:git01 -b SV46 both tell me that the remote branch is not found upstream origin, using HEAD instead.
Am I barking up the wrong tree?

First of all, using submodules for independent parts of your Central VCS repository (i.e. your CVS repo) is always good (see "What are the Git limits?").
That mean you will end up with many independent Git repo, that is "set of files evolving independently one from another", which is why submodules exist.
So multiple Git import (in multiple repo) are required.
But since git cvs import is not always up to the task, I would recommend:
cvs2svn in order to get an SVN repo first (just one repo)
svn2git in order to properly convert your SVN repo to a git one (i.e. transforming SVN branches into Git branch and SVN tags into Git tags)