Is there a way to ignore a couple lines in git? - ruby-on-rails

Question

My team and I are constantly updating our Gemfile and these 2 lines which are on line 60 and 61 in our app are constantly changing. We want them to stay the same. Is there any way we can make it so that these lines never change? but to still be able to check stuff into our Gemfile?
group :development do
gem 'ph_app', path: '/Users/joe12/Desktop/VBR/ph_app'
end

Answer 1

Another answer involving a separate file:
Use the contents of another file using eval. In your Gemfile, add these lines:
other_path = __dir__ + '/Gemfile.local'
eval File.read(other_path) if File.exists? other_path
A developer may create a Gemfile.local and add their custom gems there like so:
group :development do
gem 'ph_app', path: '/Users/joe12/Desktop/VBR/ph_app'
end
This version is not very intrusive (but for the extra lines in the Gemfile). It is very flexible since the local configuration is optional. No need to supply an empty file on production machines. This is a good solution if the gem 'ph_app' is optional in the development environment.
This solution is a bit similar to using a different Gemfile (see other answer) but configured with --local. But more flexible :)
Note that the entries for custom gems in Gemfile.lock will differ on a per developer basis. Developers will need to be careful when adding their changes to version control.

Answer 2

As requested, an answer involving an environment variable:
Use this in your Gemfile:
group :development do
gem 'ph_app', path: ENV['PH_APP_HOME']
end
And have every developer set up that environment variable in their environments. On a Linux or OSX that would typically go into ~/.bash_profile, e.g.:
export PH_APP_HOME='/Users/joe12/Desktop/VBR/ph_app'
If you run rails specific binaries from within your IDE, then you will probably have to set up the environment variable there, too.
This will not interfer on production and test environments since the :development group will not get bundled there. (You did set up those environments accordingly, right?)
Note that the respective entry in Gemfile.lock will differ on a per developer basis. Developers will need to be careful when adding their changes to version control.

Answer 3

As requested, an answer involving a separate file:
Use a non-default Gemfile as a developer. This is the least intrusive solution for the project but probably also the least convenient for the developers.
Create a Gemfile.custom alongside the Gemfile, containing developer specific gems:
eval File.read(__dir__ + '/Gemfile')
group :development do
gem 'ph_app', path: ENV['PH_APP_HOME']
end
The Gemfile.custom should be ignored by version control.
The eval is an ordinary Ruby instruction. Together with File.read it will cause the other file to be read and its contents be interpreted. You can use the bundler DSL in that other file without doing anything special.
Execute this from the project root to start using the alternate Gemfile:
bundle config --global gemfile Gemfile.custom
Using --global will set the value for all projects on the developer's machine (for that user). And here is why developers might not like this solution very much: Every bundled project on their machines will need a Gemfile.custom.
Alternatively, the custom Gemfile option can be supplied to a bundler command. That way, other projects will not be affected, but every bundler command will have to be amended with the option. Binstubs might make this more convenient, but I did not try that.
Note that the entries for custom gems in Gemfile.custom.lock will differ on a per developer basis. Developers will need to be careful when adding their changes to version control.

Answer 4

You need to use "git filters" and a combination of 'clean' and 'smudge'. The post here explains in greater detail:
How to tell git to ignore individual lines, i.e. gitignore for specific lines of code

Answer 5

An answer involving relative paths:
Do not let your developers decide where they want to put that other project ph_app but instead make them put it in the same directory as the host project. (Not nested but in the same parent directory.)
Then add this to the Gemfile:
group :development do
gem 'ph_app', version: '2.1.32', path: '../ph_app'
end
Note the added version string. Thanks to that, bundler will make sure that the local files actually provide the requested version of ph_app. Every developer will need to manually pull the most recent changes from version control. And they might also have to manually switch branches there as the host project switches branches. Maybe this could be alleviated by means of git triggers.
If needed in your production environment, you can supply ph_app in the same manner, there too. Then you will need to install the correct version of the gem with your deployment script. However, referring to your version control server (e.g. github) will be easier and also ensure that the two projects stay in sync.
The entry for the ph_app gem in the host project's Gemfile.lock will be the same for all developers. It will only include the version string, i.e. no commit hash. Nice and easy :)