Frequently when researching a problem, I come across a commit in Rails that addresses the issue.
But how does someone see which version of Rails first incorporated that fix?
For example, an issue with a missing /tmp/pid folder was fixed in this Rails commit:
https://github.com/rails/rails/commit/70e6ff2ed8596eb9bd6dcce87cb3f14015638d70
But how can I see which version of Rails included that fix?
To see what specific version includes a certain commit you need to look at the tags in the repository:
max#pop-os ~/p/rails> git tag --contains 70e6ff2ed8596eb9bd6dcce87cb3f14015638d70
v6.0.1
v6.0.1.rc1
v6.0.2
v6.0.2.1
v6.0.2.2
v6.0.2.rc1
v6.0.2.rc2
v6.0.3
v6.0.3.1
v6.0.3.2
v6.0.3.3
v6.0.3.4
v6.0.3.rc1
git branch --contains <commit id> can also be used to find new commits that are not yet tagged. Such as commits on master that haven't yet been "released".
To do this you first need to clone the repository off Github and fetch all the branches (or a least the stable branches).
Related
I searched for similar questions posted here and on the web, but none of them refer to my case.
In some way, I accidentally created a duplicate local branch as you can see in the attached screenshot. My guess is that I created it somehow when I was working with git stash with multiple stashes.
This duplicate branch appears only locally. And moreover, the command git branch in this repo returns only the master branch.
How can I fix this and remove the duplicate local branch? I do want to keep the tags in their place (and I do see them in GitHub so they indeed exist in origin/master branch although they do not appear here in origin/master). Thank you for your help
Editing due to comments:
Before all that mess I accidentally caused, I only saw a single line in the git graph (the blue one) and the tags appeared on it. there was no parallel line next to it showing the same commits. BTW, I cloned the repo to a new location and there I see what I expect - a single line with the tags appear on it. Moreover, I can't push to git from VSCode, but I do succeed in pushing from gitbash, this makes me wonder whether this is some bug in VSCode.
git log --all --graph --format=oneline --decorate prints the expected proper graph, with no duplication:
For other people facing the same issue.
I'm not sure why it happened but it was caused by the tags created using the git-graph extension in VSCode.
To fix this: manually deleted all tags locally only and then fetch them back using git fetch --all --tags.
Note that if the tag was also pushed separately (possibly create/push by another collaborator), a git fetch --tags would bring it back.
While it was not the case for the OP, the command "Git: Delete remote tag" can help, and is introduced with VSCode 1.75 (Jan. 2023) with PR 170415 from the 2020 issue 104845.
This is available in VSCode Insiders today.
I am working on a Rails project!
Excuse for not adding .gitignore
I have accidentally committed and pushed 'database.yml' in to my feature branch. A pull request was created from the feature branch to master branch a few days ago and is not yet merged. There are multiple commits done as part of this pull request and the commit containing 'database.yml' is the fourth last commit.
Others are also working as part of this project and they are merging the changes to master and we are pulling those changes in to our feature branch in-between. Thus, in our feature branch, we have got commits from others which are done after the faulty commit.
so I wish to do a 'git rm' and 'git push' the same file again to resolve this issue (as the PR is not yet merged). Will that create problem?
If you remove the database.yml that will be another commit on top, and nobody will be affected.
Notice, however, that the database.yml will still be part of the history and can be accessed via git log. If that file contains sensitive information, it will be findable by others.
Delete the file from your local system then add the changes to a commit using
git add <FILE_PATH> command and then commit and push the changes and it should be fine.
The right way to remove it properly is to reverse the changes you made to the file and commit it.
Another, dirtier way, is to open the commit and remove the changes and force push it to the repo. But you need the proper rights for this. Others will also have problems if they try to pull changes then.
I have a question. I am using Redmine for a issue tracking system for my upcoming project and I recently did the install on Heroku and I was wondering if there was a good way to use Git via a github repository to do issue tracking (ie. I can make a commit, do a refs #issue_number and it would associate that commit with the issue I'm tracking). I know there is some way to do it with svn, but we want to use git for the project. I heard that heroku is unable to do Redmine with git from someone since you need a 'bare' and 'minimum' directory? (or something similar to that) Is this true? or is there a guide out there (I've been googling 'git with heroku and redmine' and other variants for the last little bit with no luck) on installing git to associate it with my github repository for my heroku based Redmine?
Thanks in advanced!
Just to clarify, you have mentioned that you are using GitHub, Redmine, and Heroku, and want to relate commits to issue numbers within Redmine.
I believe that Heroku will not come into this, but what you want to look at is a post-receive hook for your repository on GitHub.
The best direction I can give you is to follow this documentation, but select the "Redmine" post-receive hook, and set it up according to the detailed instructions that they provide.
The documentation for the hook explicitly states the following:
Commits which are related to Redmine issues are detected by matching '#IssueNo' in the commit message (i.e "fixing bug #234" is related to issue #234)
which I believe is the functionality that you are after. Please correct me if I am wrong.
I pushed code to my server using capistrano (using git also).
I then made changes on my laptop, but haven't sinced published to the server.
I want to know which git version I pushed to the server so I can rollback to that version.
Is this possible?
I know I should have used tags but kinda late for that, hoping I can figure out the version I pushed to my server, so I can rollback to that version or at least diff from that version to the current built to see what has changed since then.
Capistrano should have put a REVISION file under #{your_app}/current on the server, with the deployed commit's SHA:
So something like:
git diff `ssh your_user#your_server "cat /path/to/your/app/current/REVISION" `
should get you the appropriate diff.
yes, you can check your reflog.
git reflog
But you should be tagging when you release.
Hope this helps
git fetch
git log origin/master -1
fetch synchronizes with your server and log origin/master shows the log of your server's git repo instead of your local repo. The -1 tells it to only show the last commit. This will show the commit hash and message of the last commit on your server's repo.
If your server is listed in your remotes as something other than origin or your server is using a branch other than master, you'll have to change that. But "origin" and "master" are the defaults and are standard convention if you haven't changed it.
<subjective>
Unless you're explicitly versioning your software (like when creating a gem, for example), it's not necessary to add a tag every time you deploy your app. This would quickly become unwieldy. With git, a commit hash can be used just like a tag if it's ever needed.</subjective>
I was wondering if the strategy I'm using for tagging and hotfixing tags (which then I use for deploying rails applications) with git is appropriate.
For tagging I just tag a commit of the master trunk.
If it happens I have to hotfix the tag, I'm checking out the tag (e.g. 1.0), fix the issue, commit it and re-tag it (e.g. 1.0.1).
Now, if I have to do another fix on the tag, I repeat the procedure, using as first checkout the tag of the first hotfix (e.g. 1.0.1).
Now, I noted two things:
1. when I checkout the 1.0.1, I get a warning saying I'm not in branch - I assume that it's ok, but is it appropriate as strategy?
2. when I try to deploy the 1.0.2, I receive an error from capistrano (tool used for deploying rails apps) during the code update from the remote repository, saying that it can't find the object [commit of 1.0.2]. I can correct this problem checking out the master and merging 1.0.2.
Of course, I'm always pushing the tags to the repository.
Is there anything wrong/inefficient/inappropriate, or this is an appropriates strategy?
I'm completely new to git and I couldn't find around a great deal of information about the deployment strategies generally used.
From the tag 1.0, you need to make a branch
$ git checkout -b hotfix1.0
on which you can go every time you need to make a fix, and on which you can make a tag (1.0.1, 1.0.2, ...) every time you need to deploy.
Working on a detached HEAd is not optimal, because that commit can be pruned later on. If you are on a detached HEAD and have made some modifications, you can always merged them with a given branch:
$ git checkout -m hotfix1.0
I would not recommend making a branch for each hotfix you need to make for the 1.0 version of your program: one branch should be enough for that purpose, with tags along the way to mark significant modifications worthy to be published.
I would suggest doing it this way:
Create a branch for your 1.0 tag, e.g. version-1 and apply the hotfix in it.
Tag the branch as 1.0.1.
For the next hotfix you can use the same branch or, if you deleted it, create a new one but this time from the tag 1.0.1.