3

My development setup is quite different to the other developers in the team - mac vs linux - docker vs vagrant

Every time I pull a new branch I have to make a load of changes to config files and docker related files to get my dev environment functioning.

I need to avoid pushing these to my working branches as they can't be merged into master.

At the moment I am leaving these files off git add and then manually adding them back every time I switch branches and perform a pull.

The following SO question suggests I could git stash and then git stash apply How to keep the git local changes without commit and apply to different repos after switch

I think that would work providing I keep my git stashes neat and the last one is restricted to my dev changes. I'm wondering if there is a better way to handle this workflow.

Can I save these changes in a dev-setup branch and use in a similar way to the stash method?

whatapalaver
  • 865
  • 13
  • 25

2 Answers2

3

One solution could be to add theses files to your locally ignored files. It is located at .git/info/exclude.
It works the same way as the usual .gitignore (see https://git-scm.com/docs/gitignore).

If the files are updated on the upstream, you will not see any modifications on the local files after a pull. And you will not be able to commit any changes to theses files until you remove them from this exclude file.

Abel
  • 688
  • 6
  • 19
  • That is really interesting. I'll give it a go and see if it does the trick for me. – whatapalaver Jul 29 '19 at 13:17
  • Actually that is brilliant and will save me ages! Just one thing to add. Most of these files were already staged for a commit so I had to `git rm --cached file_name` even though I had put them `.git/info/exclude`. This page was also useful for me on the subject as it explained the various ways to gitignore - local, global and shared https://help.github.com/en/articles/ignoring-files – whatapalaver Jul 29 '19 at 13:30
  • I'm glad I could help and thanks for the "git rm --cached file_name" I did not thought about that. – Abel Jul 29 '19 at 13:39
  • 1
    So more updates required: `git rm --cached file_name` is appropriate when we want to remove the file from the remote repo and just keep a local version. In my case I want to leave the remote version but just keep local copies with my own adjustments. `git reset -- file_name` will unstage the relevant files but these will still not be covered by the gitignore file as they have been previously tracked. This answer https://stackoverflow.com/a/20241145/3258059 shows how to remove from the indexing using `git update-index --skip-worktree ` – whatapalaver Jul 29 '19 at 15:49
1

I am adding an answer in addition to the one I accepted earlier just to bring together all the additional learnings from implementing this is my environment.

Keeping a local developer version of a gitignore file for dealing with personal dev setup

This is a super useful link about the different types of gitignore: local(personal), shared or global(all repos).

Basically to keep your own local file versions, which will remain untouched by the pushes and pulls of git, you need to:

  • add the relevant files to the personal exclude file in .git/info/exclude (thanks to the accepted answer from @Abel)

Now the remaining process will differ depending on whether:

You want to delete the files from the remote server (which will affect all users of the repo) and just keep on local:

  • Remove these from the git cache (if they are already staged) and delete remotely on the next push git rm --cached file_name

You want to leave remote files alone and have git 'forget' about your local versions and their associated remote changes

  • Remove them from staging with git reset -- file_name
  • Remove these from the git workflow with git update-index --skip-worktree <file_name>

This Stack Overflow Q&A was particularly useful Git - Difference Between 'assume-unchanged' and 'skip-worktree'

Useful code snippets if you are using skip-worktree

whatapalaver
  • 865
  • 13
  • 25