I'm using the Bitbucket (Git) with Netbeans. For some reason, a commit included a folder (build folder that contains binaries files, such as .class and .jar files) that was marked to be ignored. Now, I'm trying to delete the commit from repository and redo the commit.
Not what the questioner is asking. `git revert` adds a new commit. The reverted commit will still be in the history -- which means, in @Rafael Santini's case, all those .class and .jar files will still be taking up space in the repo (and in everyone's non-shallow clones).
Questioner is asking how to cut the commit out of the history. Git allows this (if we don't mind downstream hashes changing), but Bitbucket apparently retains these dropped commit in its auxiliary bookkeeping system: Links from Pull Requests and JIRA items will still take you to these homeless commits.
If the commit has not yet been pushed, you can use `git reset` to reset the branch to the commit before the bad commit. Beware that this changes git history and you will lose the commit(s) on the branch that occurred after the commit to which you reset the branch to.
Note: If the commit has already been pushed, you can still technically use `git reset`, but you will then have to use `--force` when pushing, which will overwrite git history on your remote git repository. Overwriting git history can be acceptable in some cases, but it is not a good idea in many cases, such as if other developers have checked out the same branch.
Also: remote repositories can be configured to prevent history re-writing, in which case you should not use `git reset` to remove pushed commits.
For your purposes (cleaning up history of your repo, reducing the size of your clones), this is possible. But, even though you can delete them from your repo (using `git revert` or `git rebase`, followed by `git push --force`), it appears not to be possible to delete the commits from Bitbucket. Such commits will not appear in your repo's history, but will remain browsable via direct URL, or from links from associated JIRA items (which are indestructable if they arise from keywords in commit-log messages).
I'm guessing this is "a feature, not a bug". I'm guessing the Bitbucket team assumed users would be more mad about:
A) broken links (users themselves caused) in pull requests, JIRA items, and commit messages
... than they would be mad about:
B.1) seeing 7 identical commits linked with a JIRA item because the dev rebased her feature branch six times.
B.2) Having no way to remove from Bitbucket an accidentally-committed secret (e.g. hard-coded password accidentally left in code, customer data file, etc).
Personally, I would have preferred it the other way. But I'm guessing I'm in the minority, because I'd bet they wouldn't have gone through the trouble of creating the duplicate storage system unless some focus-group indicated that's what people wanted.
Hey Community! I work on the Bitbucket product marketing team. With Halloween approaching, we wanted to discuss a topic tailor-made for October: development horror stories. Whether it was a lurk...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events