Delete Commit on Github through Browser - github

This is my first time using github and I was having trouble with some of the commands and committed the same thing about 7 times through terminal. I don't know how this is possible because I thought you could only commit if there are changes made in the file. I wasn't seeing anything every time I committed so I kept deleting and remaking the same repository with the same name and tried committing over and over until I finally saw them now but theres too many I just want to see 1 initial commit not all 7. I want to know if there is a way to delete a commit if I have my github account open in my browser not by using terminal.
Note on possible duplicate: Please do not mark question as duplicate. I know there are similar questions/exact same questions asked. However I have read those and most of them are commands you have to type in the terminal and because there is no way to undo that I would prefer to do this through the website. I don't want to accidentally delete something I want and not be able to get my work back later. If there is something else I can use rather then terminal I would prefer to use that instead.

If you push your commits then I'm afraid there's no way to delete them. But if you haven't pushed your commits to the remote repository, then you can change the HEAD to the previous commit.
If you had pushed your commits in a branch, and then delete the branch without merging it with any other branches (you can not delete the default and protected branches), then technically the commits will also be deleted.

Related

Regarding GitHub and version control

Recently, we have started a group project and decided to use GitHub to share the code among ourselves.
For example, if I created a login page and my friend created a home page, how can I get it on my local machine.
I mean, whenever a change is made to the repo, do we need to download it all again?
The beauty of GitHub is that you can always go back whenever you feel like.
Whenever a changed is made by any of the teammate, it's a really good practice that you push that change. Even when it's a small one. After you've pushed your changes, your teammates would need to pull that change.
The best sequence for this is;
- git commit
- git pull
- git push
You'll have to pull the changes first as it would help you avoid getting merge conflicts. If you get any merge conflicts on any line, or any function, you'll resolve that conflict and follow the same sequence once again.
So, to conclude, GitHub is so easy to use and you won't have to necessary 'Download' all the changes once again. I would recommend you to setup via Visual Studio 2019 so that it becomes easier for you to just "pull" the changes whenever a new change has been made.

Beginner help: How to remove commits to the master branch from history while keeping the changes made?

I'm new to github and have been working on a group project for school. Recently it turned out we were missing some stuff and nothing was organized (every file was just uploaded into the main directory) so I removed everything using a command in the github shell. Then I proceeded to make files and organize all the code and re-upload and store everything in there.
However, when I did this, I had to keep committing every time I made a new folder and stored a bunch of files in it. I would like to keep the changes made during those commits (because I created folders and re-uploaded the stuff), but I want to remove those commits from the history because they are cluttering up the project.
Is this possible, and if so can you please walk me through the steps. Also I'm new to github so I don't know much.
Here is a picture of the ones I want to remove from my history because they are cluttering up the screen (see red marks):
Thanks :)
EDIT: PLEASE NOTE: I don't want to revert the changes, I just want all those history to be removed because they are cluttering up the commit history.
You should use:
git rebase -i HEAD~14
To rebase and squash your unwanted commits. Just use p to mark the last commit and use f to mark the unwanted commits for squashing it with the previous commits. This will remove it from commit log keeping the changes.
More info: https://git-scm.com/book/gr/v2/%CE%94%CE%B9%CE%B1%CE%BA%CE%BB%CE%B1%CE%B4%CF%8E%CF%83%CE%B5%CE%B9%CF%82-%CF%83%CF%84%CE%BF-Git-Rebasing

Git uncomitted file confirmation when switching branches

I am using the git plugin for eclipse and I have noticed a problem with it and hoping this is a simple configuration change. Can anyone help?
When switching branches, the uncommitted changes are being merged across onto the newly checked out branch (only in certain circumstances). It seems as if this happens every time when it is "safe" to do so. The way to recreate is:
Create feature branch "branch1" from remote repository
Create feature branch "branch2" from same remote repository
Make changes on "branch2" and don't commit changes.
Switch to "branch1"
a. No confirmation message is shown.
b. The uncommitted changes from "branch2" are merged onto "branch1"
I want to be able to force the commit message to appear (just like it does using git-bash). Is this possible?
To my understanding, this behavior is intended by EGit: a checkout is performed as long as the files to be checked out do not collide with the working directory. And uncommitted changes are left as they are.
If you think EGit should offer a different strategy of handling uncommitted changes I suggest to open an enhancement request: https://eclipse.org/egit/support/
In the meanwhile, you may want to (manually) stash uncommitted changes prior to switching branches. That's what I see most people do in this situation.

Eclipse Git - Making changes at the same time

This is probably a noob question, as I only started using Eclipse Git a few days ago.
I was wondering if it was, in any way, possible to have multiple people working on different files in a repository but, when ready to commit, only have one commit for all, instead of one commit per person...?
I was also wondering if there was an option to automatically pull modified files, or a way to update the modified files in every person working in the repository, without making a commit per person first?
I'm asking this because I use Jenkins, and every time a commit is made in GitHub, it immediately starts a build, and it would be very annoying to create a commit per person just because of probably some lines of codes.
Best regards
EGit doesn't have a feature for that, but you can work around it by "squashing" the commits in GitHub. Here's how it works:
Step 1) Create a branch
Step 2) Make everyone work on that branch until it's time to commit (in your words)
Step 3) Create a pull request for merging the branch with master or whatever branch that is marked as default
Step 4) Click "Merge pull request" and then do this:
If you can't find the option to squash-merge, go to the repository settings and make sure the checkbox highlighted in this image is full:
Step 5) Confirm squash and merge

GitHub: restore old commits

I am working with the GitHub GUI on Windows.
I did some work on my project which was successfully committed about a month ago going forward. Unfortunately other person who also works on this project recently committed the files I changed without realizing that he removed a huge portion of my work.
Now my question would be: is there an easy way of restoring my commits. This is not one commit. For the past month I made several very important commits to the project which got killed by the other party error.
I really don't want to go thru each file individually and re-aaply the changes manually, especially since I already got paid for that work.
How can I get my commits back?
IF you don't see your commit anymore in the history of the repo, that would mean the other developer has done a forced push (git push --force).
In that case, use git reflog (as in this answer) to find your commits back.
If yo do see your commits, then you could revert (git revert) the commits introduced by the other developers in order to cancel them, which should leave your branch in a state reflecting your work.
In both cases, this is a communication issue: you need to coordinate with the other developer in order for both of you to agree on a state from which to move forward.