How to compare branches/states in git(hub)


EDIT: this discussion was split from here:

OK, so I don’t know exactly what you are referring to here. if you mean my broken-project workflow explanation from the post before yours, and you’d expect to do it the same way, how do you come to the conclusion that this is “disruptive to workflow”? Please don’t take offense or anything, and maybe I’ve internalized git much more than you, but I don’t see how 3-5 lines of git (or some clicks in the git-GUI program of your choice) can be disruptive.
btw, if you have problems wrangling with git at times, you can ping me on skype or mail and I’ll try to help.

ignored pull requests are another matter, and I definitely agree with you there. :slight_smile:

If your work is already on github, the quickest and probably most usable way would be github’s compare view. go to your repo, hit the Branches button, hit compare between any two branches. in the page that appears, you can edit the two points of comparison. It takes commit SHA’s, branch, and repo names iirc.
For example, this is the compare view between one of my PR branches and its branching point:…remove-printfs
compare views are generated by the URL, so you don’t really need to go into the branches view first, you can generate them by just entering a correct URL.
some reading:

The same can be done in command-line git of course, git log and git diff are your friends. For example, my above example can also be done like this:

git diff 9051c1569fa3de..remove-printfs   

I have never used that though, I normally go with some GUI for git to browsw history and get an overview.

One last word on this: I guess that you want to get all the code changes to manually “transplant” them for generating a PR (e.g. by generating a diff file from the output and putting that onto current OF/develop). If that is correct, a better way is to work with existing commits. Make sure that your commits are well-formed, i.e. always commit “isolated” changes, i.e. don’t put core changes and project changes in one commit, don’t put changes for two different features/bugs in one commit, etc. In general: “commit early, commit often”. Then it’s much cleaner to just move/copy the commits, e.g. by cherry picking or merging or rebasing

I hope this was not totally confusing. :wink:


thanks again!

i’ll try and see how quick the 3-5 lines of git works out next time

i’m in a git wrangle right now. i had to dump all my files and work on another computer really quickly, then i committed and pushed from that computer. now i’m on my old computer
now if i pull i get lots of conflicts
now i’m moving away all my local files and recloning from github… :frowning:

EDIT : no need to respond here. sorry to take it off topic.


no worries, I split the git stuff out from the original topic here


hi. i like it thanks for sharing this site.this is very informative post .