4

I have looked at numerous questions on this same topic and they all have different answers and it is confusing.

Some say commit your changes first but I don't want to do this.

I am using Git Hub too, and do not understand how this works with the website commands such as create pull request , compare across forks, try changing your base, etc...

I thought just dragging my current branch to the right square and dragging the repo master branch to the left square and then clicking the Merge Branches button would work but then there is a "sync" button on the upper right that needs to be clicked after that, I guess, and then you need to do a pull request on the website....etc...etc.

Sheesh, in CVS I just clicked update and it brought down all the changes in the Head to my current and that was that.

There are three options I guess. Using git hub, using the website, and/or using the command line. How can this be simplified?

Improve this question
6
  • To jump in on the "sheesh" implication; git isn't trying to be more complicated, it's just more robust at handling things like "undoing" the CVS update (painful in CVS) or allowing you to work through conflicts change by change. Commented Jun 2, 2015 at 15:09
  • Do you have any preference for the answer you want? (git hub tool/website/command line)? Commented Jun 2, 2015 at 15:10
  • Has your branch been pushed upstream? This governs how you should proceed; you'd get a cleaner history (avoids this) if you rebase, but you'd be rewriting history, which you shouldn't do if other users can see/pull-from your branch. Commented Jun 2, 2015 at 15:15
  • I like the github but it doesn't seem to do everything. It seems that after do something with it, you have to create a pull request on the website. Is that so? I have not pushed my branch , i don't want the committed changes in the head fork yet. I have read about 5 definitions of rebase, still don't understand it. Same for reset. Commented Jun 2, 2015 at 16:30
  • rebase takes your branch, chops it off at the bottom, then sticks it on the top of somewhere else. I.e, it re-writes history to pretend you actually branched off from some other point. Generally this is used to build your branch off the newest version of its parent branch. Commented Jun 3, 2015 at 8:16

4 Answers 4

Reset to default
6

It depends on what state your local repository is in relative to upstream.

  • If there are conflicts, then you are better off stashing your work before pulling your branch in. That can be accomplished thus:

    git add . && git stash save git pull git stash pop

    If you don't want to deal with merging, then you can rebase your branch instead, which doesn't require that you save off your work (but will prompt you for conflicts):

    git pull --rebase

    You'll have to deal with conflicts using your merge tool of choice.

  • If there are no conflicts, then you can simply pull the branch in.

    git pull

Github's role in all of this is simply to provide the remote repository in which you are pulling from/pushing to. There's no need to worry about it unless you don't have a remote set up; then I'd refer you to their wonderful documentation about getting a remote repository set up.

Improve this answer
Sign up to request clarification or add additional context in comments.

6 Comments

Personally I dislike git pull (=git fetch & git merge) as you end up with a mass of merge commits if you're frequently pulling into your development branch. It has its place, but if you're just getting the latest update for an unsubmitted (not-yet-pushed) branch you should use rebase instead.
I've added an update which includes using the --rebase option of git pull, which avoids the scenario you describe.
It was my understanding that a pull overwrites current changes in my current branch??
Git tries very hard not to overwrite any changes that you've made. If you do get a case in which that could happen, Git lets you know in the form of a conflict.
Sorry, I don't know what "head fork" means in this context. In either event, if you're genuinely worried that you'll lose your changes, go ahead and stash them, then copy the entire directory elsewhere so that you can experiment with a backup. The big thing here is that there's no one way to do what you're describing in Git, and there's no preferred way as everyone has their particulars, so you should use what is most comfortable and makes the most sense to you.
|
1

You can stash your changes in the current branch with git stash. For more information, please see this: https://git-scm.com/book/en/v1/Git-Tools-Stashing

Improve this answer

2 Comments

I want the changes I committed to the head fork from another branch in my current branch. Is this what i would use?
stash is just "temporarily squirrel these changes away for a bit whilst I do something". It doesn't effect the state of any branches, just your files on disk.
1

Your situation:

  • You're on a branch that may or may not be available upstream, which is branched from an old commit of master
  • You have no unstaged changes
  • You have uncommitted changes

"Some say commit your changes first but I don't want to do this"

There's no real reason not to; it's still your private working branch until you push it upstream.

So:

If you've not pushed yet:

  • git commit -m WorkInProgress (or git stash)
  • git rebase master
  • Resolve any conflicts
  • git stash pop if you stashed

If you have pushed already:

  • Ensure your current branch's commits are production quality
  • git stash
  • git pull (will not conflict, but will create merge commit)
  • git stash pop
Improve this answer

3 Comments

Ok so today I learned what "commit" and "push" are. So now I realize, I have committed my changes ...to my own branch, but have not pushed them upstream to the head fork. That being said, I guess i would use the top commands to update my base fork from the head fork? When i do a compare online it says there isn't anything to compare but i can see the differences in the 2 files!
Do i actually type "WorkInProgress"? Also I thought git pull overwrites changes in you current branch with a head branch that doesn't have those changes yet. This happened to me once already, thank God I made a back up.
git pull definitely does not do that, even if you have unstaged changes. It's equivalent to fetch (get information for branches/tags) + merge. You can call your in-progress commit whatever you like. I generally use "WIP" then clean-up later. As you're just learning git, stick with stash (reasoning: as you progress with git you may want to start doing multiple stashes, which gets messy quickly. Using commit (actually updating the branch) makes these multiple sets of changes easier to track).
0

You could do Patches which most IDEs and some tools provide, or if using Intellij IDEA there is a similar construct to stashing which is shelving, these changes are not persisted in git, but rather in IDEAs project files.

But in the end, for your current situation git stash is the way to go.

In the longer run, it's probably better to just read a little bit more about git, since one of the differences between it and CVS is, you have to think two phases now. You don't interact directly with your remote github or whatever. Your local repo is like your former "Save" button and the remote repo sync's with your local. And even in CVS most systems complained if you forgot to save...

Improve this answer

3 Comments

I'm using Eclipse but when i do a fetch from upstream, it says "everything up to date" when i can see a file is different in the head fork from my base fork on the website.
Yes, because that file isn't on your local branch, so is not retrieved. You'd not want an "update" on a release branch to pull in work from the development trunk it forked from.
In Eclipse "Synchronize Workspace" shows even yet untracked files, in the Team->Git->Synchronize-settings you can check "always fetch before sync...".

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.