0

I am naive in github ,I have been trying to squash the commits i have done previously on remote .But there are two problems 1)Other contributors are contributing continuously ,hence there are many commits above my commit 2)My commits are not seen in order on git hub.In the snapshot ,it is the four commits I have to merge enter image description hereAny help will be appreciable .

aayush
  • 85
  • 1
  • 6
  • 1
    Assuming you've been following best practice and done you're work on your own branch, squash on the branch BEFORE merging the change into master. If you're the owner of the repo submit rebase requests. – marblewraith Dec 24 '15 at 20:50

2 Answers2

1

I would recommend always working on a local git branch that is not tracking an upstream branch. That is, when beginning new work on a remote branch named gh-pages, create two local branches, as follows: 

# Create local gh-pages branch to track upstream
$ git co -b gh-pages origin/gh-pages
# Create personal branch for changes to be pushed to gh-pages
$ git co -b aayusharora-gh-pages

As new commits to gh-pages are pushed to upstream, pull them into your local gh-pages branch, and then rebase them on top of your aayusharora-gh-pages branch. That is, periodically do this:

# Check for new changes upstream
$ git co gh-pages
$ git pull
# Rebase your changes on top of any upstream changes
$ git co aayusharora-gh-pages
$ git rebase gh-pages

This will ensure that your work is always 'on top of' any upstream changes. When you're finally ready to push your changes, do:

$ git co gh-pages
$ git merge aayusharora-gh-pages
$ git push
# If finished, delete personal branch
$ git br -d aayusharora-gh-pages

Working this way will ensure that any changes you accumulate while working on a task will appear to be the most recent commits when you finally decide to push them. Until then, you can rebase/squash any commits on aayusharora-gh-pages to make the commit sequence look any way you want.

evadeflow
  • 4,704
  • 38
  • 51
  • 1
    Why not use git pull --rebase ? – exussum Dec 24 '15 at 22:31
  • I occasionally use `git pull --rebase`, but I find that workflow to be confusing when there are nasty merge conflicts with changes pulled from upstream. With git, you automatically get a `master` branch that tracks `origin/master`, and it is _super_ common to create a topic branch for each new feature to be pushed to `origin/master`. To me, it's a logical extension of that workflow to create a local tracking branch for (non-`master`) remote branches, and a _topic_ branch for staging changes to it. – evadeflow Dec 26 '15 at 17:56
  • That doesn't seem a common workflow. If it works well for you though use it – exussum Dec 26 '15 at 18:15
  • Thanks @evadeflow ,but can you explain Do all the steps like git add . and git commit will take place after git merge aayusharora-gh-pages – aayush Dec 30 '15 at 12:17
  • Yes, @aayush, if you always rebase changes from the upstream `gh-pages` branch onto your `aayusharora-gh-pages` topic branch, your changes will always appear _after_ the upstream changes when you do the final merge/push. That's the essence of rebasing: it applies your changes 'on top of' other changes. Just don't try to rebase commits you've already pushed—that will lead to problems. (See [this link](https://git-scm.com/book/en/v2/Git-Branching-Rebasing) for a detailed explanation of rebasing.) – evadeflow Dec 31 '15 at 17:13
0

If you have both the origin and upstream do

 git fetch upstream
 git reset upstream/gh-pages
 git commit

That will reset your local branch to the upstream version. Keeping the changes in your staging area. Assuming all is OK commit and it will be just the difference of yours

exussum
  • 18,275
  • 8
  • 32
  • 65
  • Thanks @exussum,but it is not doing any merges on local machine,means I can not see the changes of other with combination of what I have done on my local machine – aayush Dec 30 '15 at 12:24