search

jatwell93 / rubyproject

1 stars 1 forks source link

contributing #26

Closed Mirv closed 7 years ago

Mirv commented 7 years ago

I've never done contributing style uploads before - normally I fork & branch like the two pulls you have thus far. In order to pull your changes regularly & not blow out my other branches, I need to be a contributor on your project apparently, as it points the origin of my c9 at your repo. As once you update the master branch - I'm potentially submitting dirty pulls.

If you're comfortable with me as contributor send me an invite.

Otherwise I'll make the next pull request, wait for it to go through & check back in a few days from your accepting before I then delete the cloned repo & down load it fresh to github & repeat.

jatwell93 commented 7 years ago

@Mirv i think i've added you as a collaborator now :)

jatwell93 commented 7 years ago

Hey @Mirv i was making changes on the recipeVersion2 branch but cant commit them because of this error To github.com:jatwell93/rubyproject.git ! [rejected] recipeVersion2 -> recipeVersion2 (non-fast-forward) error: failed to push some refs to 'git@github.com:jatwell93/rubyproject.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

is the correct way to fix this git pull origin recipeVersion2? Then push? Sorry just dont want to screw up any of your code etc.

Mirv commented 7 years ago

From what I've read in the past - one of two things is happening:

  1. If you are using c9's console to preform these commands, your local repository at c9 has uncommitted changes.

  2. The github repopository branch recipeVersion2 is out of sync with master & the pull request see's at least one file conflicting with a file in the other repository.

Normally I do the branch merge thing & sometimes destroy the branch afterwards. I'm lead to believe that there is also some way of surgically taking commits without taking the whole branch in a shared repository (which i haven't done). This will normally induce a file to be created with comments at each section you need to change.

This part drove me insane the first time I had to merge something with conflict - highly recommend avoiding & that normally means not letting the branches diverge too far or not working on the same things.

With both of us in a repository - we need a slightly different workflow. I haven't done this before either, but from what I understand we need to sync our branch to any changes before we start work for that day. I'm told get Fetch is what we need to do daily, then merge, but the internet seems to think they are the same as a Pull (indepth here - Link). I'm also brushing up on the official remote work for 'git' too - Link

What to do now, to get the master branch working ...

  1. Compare the difference use something like one of these answers - How to compare origin (master on github) to local branch - Link. Based on that you decide if you want to do the merge manually or you can either dump your copy or their copy throwing away all changes from one version. `git checkout --<theirs/yours> <path/file>'

  2. There's got to be a commit merge process which will probably suck - I found a Stackoverlfow for mergetool - Link. Git documentation - Link

  3. There's probably a way to replay the commit, from new branch we start off master

  4. There's rebasing - which blows out any differences on the master - S/O link

  5. Theoretically, if we can't get it working - we manually copy & paste the changes to the master & just delete the branch after master is working - swearing never to speak on the internet of our secret shame :)

Mirv commented 7 years ago

Unexpectedly - my clone of your github rubyproject is automatically talking to your github repo since you made me contributer ... I'm going to have to study that one some, as all of my test branch saves will be notifying you - even if I don't want them too :)

Mirv commented 7 years ago

Got it ... rather than trying to second guess why you did anything, after the 2nd hour pondering the git guts of the commits I decided to just accept your changes off recipeVersion2.

For you to resolve your issues, you will need to

  1. git pull origin master

  2. Open the file in question with conflicts off the list

  3. Scroll to where it shows some highlighted code. Here I can't guide you - you either need to select "use" on the code conflict. Git will have added a comment after the line "ours" or the "theirs" version with the little buttons that show up.

  4. Do a 'git add <path/filename>' for each file changed. You could do a 'git add -A', but that's really bad practice.

  5. Do a 'git commit -m "".

Viola! You are now up to date.

After this happens - always start a new branch before making changes. Once it's ready & tested, add it & the tests back to the master by normal merge. As long as you are regularly merging it will always accept your changes - its when you get two changes away from the branch that it will start rejecting & call for merges in conflicts.

jatwell93 commented 7 years ago

You're amazing, thanks so much for all that info i feel like i'm starting to finally understand git. i followed those commands and everything seems to be working again! I started panicking thinking i managed to wreck all your hard work hahaha. AAlright from now on ill following your example on the other issue.

Mirv commented 7 years ago

Thanks - I'm really not that great with git either - but seriously - once it's committed unless you rebase or squash commit's it's always there!