How do you work with different computer?

I have never used Heroku but if you stop coding on native Windows it would be a good start :-) Try using virtual machines or docker for your local development.

You should always use a .gitignore else you will end up committing your vendor folder to github amongst other stuff. And be sure you have committed your composer.lock file also.

Good luck.

@CJJ Greeting,

You're right. I might should've switch to Ubuntu but since it's the office desktop, it would require a lot of permission and that take time to approve from boss or whoever in charge just to set new OS. I never use docker before and maybe I should give it a try.

You can stay with a windows desktop just use virtual machines/docker containers. Docker is very good but can confusing to start. If you can convince your team mates to embrace the learning curve I would highly recommend it. There is now also Docker for Windows https://www.docker.com/docker-windows

Use homestead, no need to switch OS. https://laravel.com/docs/5.5/homestead

+1 homestead

I'm developing on two Windows 10 machines, one with Wamp, the other with Xampp. In the office, there are two guys running Linux. Both our staging as our live server are Linux. Honestly, if yo configure things right, it doesn't matter what OS you are using.

Regarding GIT: Personally, I'm cheating. I haven't ignored my vendor folders. They're included in my repository. Yes, it makes for a bigger repo, but yes, it also means I only need to run composer update once. Just make the commits and push them as you are used to, the pull (or fetch+local merge if you are using GITGUI) before you continue on your home environment.

@Thyrosis That seem like a great idea. No one has ever give me a good reason to use .gitignore at all.

@Thyrosis @GTHell

Reasons to use .gitignore

1. Per-developer configuration files.
2. Per-environment configuration files.
3. Avoid local junk such as log files being deployed into foreign environments.
4. Hard to identify changes to your source code if your commit also includes updates to 1000's of 3rd party vendor files.
5. Merge and conflicts. If you have many feature branches and each branch contains a copy of your vendor folder you will get into a mess / waste a lot of time trying to resolve unnecessary conflicts.

Best practice; Avoid any files that can be generated by simply building your project. There is a list of .gitignore templates at https://github.com/github/gitignore, a repo with 57,000 stars.

I'm sure I can probably think of a few more examples but the pros of using a .gitignore far outweigh the cons.

I use homestead never had any issues with it although testing can be slow on an SQL database (prefer SQLite in memory wherever possible).

One more thing is that I'm not so sure about heroku app. I heroku create on the other machine and I can't heroku open it on my machine.

@GTHell It’s because Heroku uses Git remotes to work out which Heroku app to open. When you create a Heroku app on one computer it will also set a remote called heroku (run git remotes to see this). When you clone your repository on another computer, it won’t have that remote set (again, run git remotes and you’ll just have origin listed).

So you need to add the heroku remote (git remote add heroku https​://​git.heroku.com/your-app-name.git) on your other computers, and then you’ll be able to open your apps with heroku open.

@CJJ I didn't notice about that. Thank for remind of avoiding that headache.

@martinbean Yeah, I just figured that out. I should do more research next time.

@CJJ Ah maybe I was misunderstood. I do of course use a .gitignore file for all those things you mentioned, except for number 4. For my composer updates I do a separate commit.

But apart from that, I'm still ignoring .env for environment-based settings, logs, storage and the like.

@Thyrosis Each to their own no harm done :-) I'm sure you appreciate your approach is quite unconventional. I've never seen a vendor/node_modules folder under revision control before.