0

I just realized that my coworker has merged my feature branch into the master branch in Github, while I have been continuing working on my feature branch on my local machine since his merge. Now I have just git add some new changes on the feature branch, without git commit yet.

If I realized that immediately when he made the merge, I would have pulled the master and then create a new feature branch and work on the new feature branch.

What shall I do now? Will the answer be different, depending on whether I have run git add, git commit, or git push?

Thanks.

Tim
  • 1
  • 141
  • 372
  • 590
  • Talk to them about it? The fact that you were still working on the branch when they merged it in suggests a breakdown in communication along the way. – Makoto Jan 08 '18 at 17:20
  • Lots of options here. You could just `git stash` your work, then create the new branch off master, the `git pop` your work and away you go. – jmargolisvt Jan 08 '18 at 17:20
  • Just rebase your feature branch on `master` and continue working. Nothing else is necessary. – larsks Jan 08 '18 at 17:21
  • The answer purely depends on what exactly you want to achieve and what changes you would like to see in those branches. – Srini V Jan 08 '18 at 17:21
  • @larsks: Thanks. Could you give specific commands for me to try? I am not confident with rebase or git in general yet. – Tim Jan 08 '18 at 17:23
  • https://git-scm.com/docs/git-rebase – Srini V Jan 08 '18 at 17:24
  • @jmargolisvt Thanks. Could you give specific commands and steps for using stash and pop? Last time when I used it, I messed things up and am now very cautious. – Tim Jan 08 '18 at 18:29

2 Answers2

2

I am not confident with rebase or git in general yet.

Remember, you can always just make a copy of your repository and try things out there without worrying about mucking things up. In fact, if you are running commands you're not familiar with recommended by people you don't know, this is probably a good idea in general.

Could you give specific commands for me to try?

First, make sure you have an up-to-date copy of the remote repository:

git remote update

Next, make sure you are on your feature branch:

git checkout myfeature

And finally, rebase onto the updated master branch:

git rebase origin/master

Depending on the changes in master since you created your feature branch you may need to perform some conflict resolution. If the only changes was that your feature branch was merged, you shouldn't have to correct anything.

(Note that the above assumes you are working with a remote named origin, which is common but not guaranteed.)

larsks
  • 277,717
  • 41
  • 399
  • 399
  • Thanks. Before I tried your suggestion (i.e. `git remote update`), should I go ahead and make a commit on my feature branch, without push? – Tim Jan 08 '18 at 17:34
  • Yes, in order to rebase your feature branch you will need to either commit or stash any pending changes. – larsks Jan 08 '18 at 17:35
  • After rebasing, will I get a new branch, or will I still be on the same feature branch as before rebasing, and the feature branch has lost the previous commits that I made? – Tim Jan 08 '18 at 18:27
  • @Tim: the first thing to remember about Git is that it does almost everything by *hash ID*. Names like `feature` are ways to specify some particular hash ID. A hash ID will name one specific commit; that commit will name its *parent* commit (by ID), which will name its own parent, and so on. What `git rebase` does is to *copy* (some) commits, then take the existing name and make it point to the tip-most copied commit. The original (before-copying) commits still exist, but now some of them have no easy way to *find* them, since the *name* (`feature`) now finds the *new* commits instead. – torek Jan 08 '18 at 18:32
1

You can git stash those changes while you create a new branch. git checkout <<master branch name>> then git checkout -b <<new topic branch name>>.

You've got a clean copy of master now, so let's get those stashed changes with git stash pop. Now you're back to where you started, with all your already committed changes in the trunk and your new changes ready for commit.

jmargolisvt
  • 5,722
  • 4
  • 29
  • 46
  • Thanks. I just ran `git stash` without running `git reset HEAD .` first. and then `git checkout master`, `git pull`, `git checkout -b newbranch`. I was wondering what is the potential consequence when missing `git reset HEAD .`? – Tim Jan 08 '18 at 19:11
  • Any staged changes would not have been stashed. If you were able to switch branches without warning, that tells me you had no staged changes. – jmargolisvt Jan 08 '18 at 19:16
  • I just checked. My original feature branch doesn't have the stashed changes, while my new feature branch has. Was wondering why it works without `git reset HEAD .`? What does the missing command mean? – Tim Jan 08 '18 at 19:22
  • It undoes `git add .` – jmargolisvt Jan 08 '18 at 19:24
  • Does `git stash` apply to the changes already in stage (made by `git add`)? or only to changes in working directory? Or both? – Tim Jan 08 '18 at 19:24
  • The link only mentions changes in working directory. It doesn't say changes in stage, but that doesn't say `git stash` doesn't apply to changes in stage (i.e. made by `git add`), correct? – Tim Jan 08 '18 at 19:32
  • @jmargolist Is it a misunderstanding on my part? I read git stash man page also and I saw there that your staged changes go in the stash. I tried it out just now and it does... – Romain Valeri Jan 22 '19 at 22:52
  • No, you're right. The unstaging is not needed here. Edited accordingly. Sorry for the confusion. – jmargolisvt Jan 23 '19 at 03:50