GitHub: How to squash multiple commits?

General Discussion
1

So I’m a complete and utter newbie with GitHub. I’ve signed up, used the instructions to link by account, forked the ST master, but man, I really don’t understand fully what I’m doing there yet. I know with enough work at it I might eventually be able to get slightly more proficient, but I don’t know that I’ll ever invest the time as I’m really just a light hobby coder at best.

I’ve only ever used it website, I’ve never used the Windows Client or the Command Line. Over the last few days I’ve made some minor changes to one of my apps that I’m trying to get out there and it appears to have resulted in multiple minor commits.

I got an email from someone asking me to squash the commits together to make it cleaner, which makes sense. But I have no idea how to do that. I found some instructions on how to do that via command line commands, but this doesn’t seem to work for me, possible because I never sent the commits from command line?

Is there a way to squash commits via the GitHub website? Is there a way to access commits generated via ST’s IDE or via GitHub’s website with the git command line?

I wanna make sure I’m doing things “by the book” here, but I guess I’m in a little over my head.

1 Like
2

I empathize with you Chris; though… I found Git really plays around with my OCD.

Truth is there is no single short answer (though there are many good “how to’s” out there).

  • I can give you a more specific answer (or reference) when I know more about your scenario.

(In my opinion, Git isn’t hard so much as being scary. There are many commands that do very powerful things with just a couple flags, but you are warned not to do this or that, or here is the dozen commands you’ll have to run if you messed up.)

The Short Answer: It really is very seldom necessary to “squash commits together”. Git maintains history very efficiently (just records the minimal incremental updates to each file), so it’s not a space issue. You can easily add Tags to any commit on a repo and that makes it easy to find points in a long bulky history that are important to you or to whom you share. In other words, just using git commit and git tag will let you get a huge value from Git with no risk. As far as I know, this is the #1 most common answer to your question. But…

I can offer some random generalizations to keep in mind:

  1. If you are the single user of a repo (repository), i.e., nobody else directly commits to your repo, and it is very unlikely anybody is going to fork your repo and make requests to have you pull stuff back into your repo, etc; then life is much much easier, as you can violate a lot of Git “rules” and still not lose any important data. At most you’ll lose some change history and commit log messages. And if you are truly using a personal repo, you can make a complete clone of it as a backup and know that it won’t go out of sync with others’ activities.

  2. If the above conditions are not true – i.e., you are in a collaborative situation on a repo with other people using it directly or by forking and pull requests, then any sort of “cleanup maintenance” has a high probability of messing everyone else up. If they are sharing the repo directly, they suddenly might not be able to commit and get lots of merge conflicts. If they are tracking a fork, same thing. If they are issuing pull requests to you, then, well, you get to deal with the merge conflict.

  3. Git repo administrative maintenance is probably best done by understanding the branch and merge-or-rebase process. I bet 80% of folks on GitHub do all their work on the endlessly growing master branch (see my Short Answer above). It’s not pretty, but it is sufficient. To reduce the “mess”, the 20% do day to day work (i.e., frequent commits) to development branch(es), and fold (merge or rebase) these into the master, and then the development branch can be deleted and a new one started, or you can let it grow, knowing your master is the clean room.

  4. Even if you are very command line oriented, I highly recommend SourceTree (free) as your Git client. It lets you flip through your commit log and dynamically view diffs, create branches, initiate merges, add tags, etc., with just a few clicks. But most valuably, it graphically depicts the branches and tags much better than GitHub or even GitHub for Windows. And as a nice bonus: Atlassian (the developers of SourceTree) have quite concise and helpful blogs and how-to pages that explain Git concepts and best practices. https://www.sourcetreeapp.com/

  5. When deciding what type of branching and tagging structure you want to use, you can compare various choices, but I really like the NVIE model described and pictured in this rather short article; http://nvie.com/posts/a-successful-git-branching-model/

  6. #4 and #5 go really well together. The various branches and merges NVIE calls for are easy depicted in the graphical view provided by SourceTree.

And finally…

and

2 Likes
3

got the samew email. and asked what they meant because I only commit as I make changes.

4

Who is sending you these “emails”??

5

Kristofer Schaller notifications@github.com

So, might just be an automated email if the system sees x-number of commits within a given time frame.

6

Ah…

I can help better if I understand the context. Is this for a SmartApp being submitted for publication or just a SmartThings GitHub integration sync’d repo or ?

In other words … why does Kris care about your repo anyway?

7

Well, being the newbie that I was I assumed that “Kris” has taken particular interest in my SmartApp… after all, it was a pretty good app… set to revolutionize the world! (okay, maybe not so much…)

Now that I actual looked at the address I can see that it’s probably a generically generated message and probably isn’t something to get too hot and bothered with.

8

Now you’ve got me crazy curious…

This seems like a really silly thing for SmartThings to be sending out, but perhaps there’s some “good” reason. Frankly, maybe the IDE integration with SmartThings has trouble processing a long commit log, or something weird like that.

Do you mind pasting or sending me a copy of the email?

9

I think it’s coming from Github, not SmartThings. notifications@github.com

1 Like
10

Now I’m even more curious! :cat:

I’ve never seen such a notification and still would love to…, please? :worried:

11

I got the same notification within Github. Kris commented on my pull request asking me to squash my commits. I wish I had saved the exact sequence of commands that I used so I could share here. something along these lines:

#while working within my branch
git fetch SmartThingsCommunity
git rebase -i SmartThingsCommunity/master
git push -f origin MSA-591-2 (<--your branch goes here)

If you break things (I did on the first try…), you can reset to before the rebase by doing a ‘git reset --hard ORIG_HEAD’

For reference

12

I’m going absolutely crazy nutso here.

Why the heck is anybody asking anybody to reduce the number of commits in anybody’s repo??? :confounded:

Would someone please share the emails and the details (i.e., exactly what repo, and if it is a public repo, what files involved?).

I super appreciate it. This is just an OCD thing here… there is no reason to force people to squash commits… except to make a pull request easier to summarize and integrate… oh… :grimacing:

13

Here is a couple good references:

Follow-up

This is a philosophical thing. Honestly each individual is going to have reasons for squashing commits and not squashing commits. One or the other is not wrong, it comes down to preference and we have decided we like clean commits to keep version history clean as we commit on a daily basis and the ever growing list of commits can become unmanageable.

Here is a good article talking about the pros and cons to each philosophy.

1 Like
14

This was a pull request that I had submitted to the ST community repo, so not my personal repo. You can see the comment here:

15

I saw some of the instructions on how to do this (assuming I even really need to do this) but the problem was I could seem to access my repos from the Git command line. I did everything either through ST IDE or through GitHub.com and it looks like you have to command line 'em to geto this squash stuff.

1 Like
16

@chrisb

What did you submit?

17

Goodnight SmartHome – name space is: sirhcb

1 Like
18

Thank-you!!!

Now everything makes much more sense.

In my initial response to @chrisb above, I had no idea he was working on a pull request.

This “mess” is a bit of a side effect of folks doing all their in-progress commits to master instead of keeping a separate develop branch. If you keep your own copy of the repo “clean” (i.e., master is only used for consolidated commits of working code, develop or others are used for unlimited commits), then if you pull from master, the number of commits will be very small and no more squashing should be required.

Git repo administrative maintenance is probably best done by understanding the branch and merge-or-rebase process. I bet 80% of folks on GitHub do all their work on the endlessly growing master branch (see my Short Answer above). It’s not pretty, but it is sufficient. To reduce the “mess”, the 20% do day to day work (i.e., frequent commits) to development branch(es), and fold (merge or rebase) these into the master, and then the development branch can be deleted and a new one started, or you can let it grow, knowing your master is the clean room.