Git commit and then pull in branch, from master. Loosing everything?

Question

I am working on a completely different structure from the one on master branch, on a On Rails app in a local branch. I am comiting everything and then pushing my changes to a remote branch as well. At some point in future, I would like to integrate my changes back into master, but I want to make it even first, so I won't be behind it, just ahead by n commits. If I am doing a

git pull origin master

into my branch and then push that, would I loose anything from my previous commits, or would those stay on top of the master branch ones? In theory I should be able to merge my branch, as I will only be ahead of master, but I am not entirely sure if that's how git is working

Answer 1

you will not lose data when you do a PULL but you will get merge issues which you will need to fix.

While technically you can push without pulling (with --force flag), you should not do that, because it discards other people's work. First pull their changes, resolve conflicts and only then you can push.

Piece of advice, try to make your units of work small, as in don't spend too much time away from master especially if master gets updated frequently. The reason is that you will have a very difficult time merging.

Answer 2

Never do significant work on the master branch. The only time you are really working on the master branch is when you are merging or if you are the lone programmer on a project (even then its questionable).

When working on a feature or taking care of a bug you want to be working on a separate branch.

For example when I take an issue from the product tracker I create a topical branch based on the name of the issue:

git checkout -b 136-fix-something-important

If the work on a topical branch takes a long time you keep up to date with the remote by pulling the changes into the master branch and rebasing your topical branch off master.

git status # make sure you have a clean slate otherwise stash or commit
git checkout master
git pull
git checkout 136-fix-something-important
git rebase master 

This would fast-forward 136-fix-something-important if there are no conflicts or you would have to resolve the conflicts. However taking care of conflicts is better done early that later in a mega merge.

When you are done with the feature in your topical branch you either merge it (if you are a maintainer) or send a pull request (if you are a contributor).

So what do I do now?

Move your work to a separate branch. And reset your local master branch from origin/master:

git branch mybranchname
git reset --hard origin/master
git checkout mybranchname

You can the rebase your work in mybranchname off master.

git rebase master

Answer 3

Other answers aren't wrong, but it would be cleanest to push to a remote branch, pull to local master from remote master, then locally merge master into your local feature branch.

Then, your changes wouldn't be lost, merge conflicts could easily be resolved, and you won't rewrite any other potentially collaborative history with rebase.