There is a project on GitHub that I have forked. My workflow involves cloning my fork to my local machine.
Occassionally I commit my changes to my local branch. And eventually I push those changes to my fork on GitHub. I do this so I can work on my project at work, push my changes, then go home, pull the latest from my fork and continue working.
At this point, on my branch, I have several commits. I want to link my changes to some people for code reviews, but when I view an individual commit, it's diff is only compared to the previous commit from me. I don't want my peers to have to sift through all my commits trying to understand what changed from the beginning.
Is it possible to specify exactly which commit you are diffing against? In my case, I want to diff my latest commit against the latest commit in the origin branch.
If not, is there a way to rebase a fork on GitHub so that it combines my selected commits into one commit?
In most git based code reviews, it's normal practice to go through and review every commit and comment separately for each one. This is normally to help enforce good coding practices in terms of commit size and scope and testability.
In the command line, almost all commands support a revision interval as an argument
git diff <some commit>..<some other commit>
git log <some commit>..<some other commit>
and that will give you the results for changes solely within that range
also there is a difference between
git diff <some commit>..<some other commit>
and
git diff <some commit>...<some other commit>
as the third dot means inclusive, also showing results for which defaults to HEAD
In the github web client I don't think you can do this, I just checked their native client and it's a no go as well.
I did just look at Atlassian/bitbucket's SourceTree and that allows you to shift-select a range of commits as you're expecting
Related
I am newbie using Gerrit review flow and previously had good experience in GitHub and GitLab.
But looks Gerrit review system works bit different.
So I have created one feature branch called feature/test. This branch contains one test commit and this commit has been pushed to Gerrit.
Change can be seen Gerrit with unique change id and commit.
Now the problem is, on this feature branch 3 developers will work and they need to continuously fetch each other changes with same change id.
Can someone help on this, what I need to do. because when I pulled this feature branch with one test commit then change is not visible to me at different place.
I didn't understand what you mean by "fetch each other changes WITH SAME CHANGE ID". A Change-Id is a unique number that identifies a change in Gerrit. Each change made by each developer will have different Change-Ids.
The better process to work on Gerrit is the following:
1- Update the local repository
git fetch
2- Create a work branch based on the remote branch:
git checkout -b work1 origin/feature/test
3- Make your change and commit
git add
git commit
4- Push your change to review on Gerrit:
git push origin HEAD:refs/for/feature/test
If the reviewer suggests something to do:
1- Checkout the work branch
git checkout work1
2- Fix your change and commit
git add
git commit --amend
3- Push the fix to Gerrit:
git push origin HEAD:refs/for/feature/test
All developers can work in parallel using the same process. You can also work in parallel by creating other work branches (work2, work3, etc) while is waiting for review. Avoid serializing the commits by always basing your work branches in the remote branch and not in your previous work branch.
When the feature branch is read, it can be merged in the master (main, release, or whatever it is called) branch.
I have a fork of microsoft/vscode-arduino on github. Some time ago I submitted a PR that was accepted. Time passed and now I want to do some more work.
At the time my use of git and github weren't very sophisticated and I rather foolishly did all the work on master.
On my local repo I pulled from upstream master, merged and committed to my fork, and was surprised to find that github thinks my fork is still 7 commits ahead and 113 behind.
Then I tried to rebase on the upstream as described on this page My pull request has been merged, what to do next? but the command
git pull --rebase origin master
and after a bit of mucking about I'm no commits behind and 12 commits ahead.
I really don't care about preserving anything. Everything important has long since been merged into the upstream repo. I just want to make this main exactly the same as current main in the upstream, so I can branch for my new efforts fixing an ongoing problem where every time there's a release of VS Code that uses a different version of node it breaks the serial port native integration until the Arduino extension is updated to the same release of Node and released.
Can anyone advise on how to do that? (discard the 12 commits ahead, not the N-API thing)
This may not be the most elegant but it worked.
Use GitLens in VS Code to find the oldest commit that isn't mine and do a hard reset to that.
In the terminal pane, git push --force. Refreshing the github page it now says I'm two commits behind origin (the repo I forked). I'm rid of the unwanted commits. Now to work forward.
In VS Code terminal pane git pull --rebase upstream master
In VS Code click on the status bar to sync.
Refresh the github web page. Hooray, This branch is even with microsoft:master.
I am a newbie in the GitHub world. I've been working on a project for my coding bootcamp. I had everything working just right to the specifications of the project and I was all done. Then I foolishly seem to have committed an old early version of the project, thus covering over the final version. I have tried to revert the last commit from the GitHub website, but the interface does not seem to follow the instructions. I tried the "git revert {commit#}'" command from my terminal, but that did not work either. I need suggestions. I'd like to get it done from the command line if possible.
git revert commits a reverse change, so from the history point of view you will have two unnecessary commits that cancel each other. The {commit#} in your case should be the ID of the commit that you want to undo (= the last one). This should work as long as there are no other commits on top of it, otherwise you might get conflicts which require more work.
If you don't have any other commits apart from the one you want to undo, there is also a better way - simply move the branch back to point to the last commit you want to keep (= one before last).
Something like this (I assume you are working on master, that you didn't do revert yet and that there are no other people involved):
git checkout -b tmp_branch master~1
git branch -f master tmp_branch
git checkout master
git branch -D tmp_branch
git push -f origin master
And voilà. If your master is protected in GitHub, you will have to unprotect it. You can repeat this to go further back (or just use ~2, ~3 etc.)
There is a certain commit I did to my Git repository which I host in GitHub. After that commit I've made several other commits, which were bad and redundant, in a second look. I thus need to revert to the certain commit / certain point in history before these bad changes.
I didn't find a button like "revert to this version" or "commit this version as the head of this branch (master)".
As you can see, I just want to make that older version the head of the master branch. How will you do that from GitHub?
Update
I emphasize: I ask on GitHub, not on git or any GUI other than GitHub.
If I understand you correctly you want a past commit as the last commit on the branch.
If so, using examples with origin and master:
Use git reset <comit_id> and then git push origin +master to push & delete all commits past the one you reset to. Notice the + sign before the branch name (master).
Note that this is irreversible (as far as I know) so take the necessary precautions.
I have a git project that I'm about to push to SourceForge. The origin for my local repo is a shared file system repo that gives me a backup facility.
When I eventually add SF as another remote I just want to push the latest (= versioned) commit to it as the starting base of my code on that repo, and not include all the previous commits that contain possibly rubbish/sensitive/embarrassing code.
My question is similar to this one, except that question was about just leaving out some of the history - I want to leave out all of the history and have the latest commit to become the starting point of the project code on SF. Importantly, having done this, I want "push to upstream" to continue to work even though origin and SF will be different.
Is this possible? Incidentally I'm doing this through Eclipse ie. eGit.
Update
My original question should have been clearer, although the answers so far have helped clarify exactly what I'm trying to achieve.
I want just consolidated commits pushed to SF, representing the published versions.
This is what I want to do:
[master] A--B--C--D--E--F--G--H--I... --> push to origin (private)
\ \
[public] V1----------V2... --> push to public remote repo
#michas's answer starts me off with V1 on branch public, but I can't figure out how to continue to extend this branch with subsequent version commits. I've experimented with rebase but can't get the result I want.
It sounds like you want to start with a new repo. Why don't you just delete or rename your old repo and create a brand new one. Then copy all of your files in, commit them, and push.
Well, you cannot push the current commit, as this commit contains the whole "rubbish" history.
However you can create a new commit with the same content but without any history.
git checkout --orphan fresh # create a new branch called `fresh` without any history
git commit # add your work as a new commit
git diff fresh master # the both branches should contain the same content (assuming you original branch was called `master`)
git log # verify the current branch does not contain any history
git push sf fresh # push that branch
git push sf fresh:master # (or you might want to call that branch master on sf)
The answer provided by #michas didn't allow me to subsequently maintain the branch with consolidated history. This required the use of git merge --squash. The scheme I eventually came up with was similar to the one described here.
Just tidying up so the question has an upvoted answer.