Page 7 of 7
The following is a basic git workflow that handles most users needs:
The big picture:
We will have the following branches on our repository:
- Master branch: to be used as the trunk of your repository tree, this branch will be where all the other branches stem from.
- Development branch: the latest branch to use on your dev environment.
- Staging branch: the latest branch that will run in as close as possible to our production environment.
- Production branch: the latest code for production will be here.
Workflow:
Sprout a branch from master to work on your feature.
Read More...
Bash when is executed as interactive, uses environment variables to define how the shell prompt looks in different scenarios. One of those variables is PS1, this variable is used to define the prompt displayed when the shell is ready to read a command(this is the one we will normally refer to when we say we would like to customize our prompt).
There are more variables like: PS2 is displayed when the shell needs more input to complete a command, or PS0 that is displayed after it reads a command but before it is executed. But we will only focus on PS1 just now, there is more information on the man page of bash (run the command man bash and search for PS1).
Read More...
When we use:
1
| bundle update specific_gem
|
We expect to only update one gem the one we are telling bundler to update but that is not the case it updates the gem and all its dependencies, and if the dependencies have updates but the gem doesn’t the dependencies get updated no matter what.
so to avoid that use:
1
| bundle update --source specific_gem
|
And that should do the trick.
Read More...
I’m giving Fish shell a try, you can grab my set up from github (fish setup).
There are a few details worth pointing, most of the configuration is done by the functions inside:
1
| $HOME/.config/fish/functions
|
- Aliases are better created by defining functions that are autoloaded.
- Prompt is defined by the following functions:
1
2
3
| fish_prompt.fish
fish_right_prompt.fish
fish_mode_prompt.fish # if you are using vi mode
|
Use fisherman to manage your plugins
Read More...
Development environment will use:
WordPress latest - the image uses Apache
MariaDB latest
I would like to keep the WordPress files in the host machine so I can tinker with them so we’ll be using a mount defined by the environment variable: WPHOME
so let’s say we have the following directory schema:
└── wordpress-development
├── WordPress/
└── docker/
inside the docker directory is where the docker-compose.yml (you can see the docker-compose file at the end of the post) file is located, so the command I will run to bring the containers up will look like this for my example:
$ WPHOME=../WordPress/ docker-compose up -d
Read More...
After merging a pull request Github shows the option to remove the branch that was merged, but that only removes the branch from the remote Github repo.
If you display all your branches in local( git branch -a ) you’ll still see that the removed branch still appear.
To verify which branches are ok to remove you use the command:
1
| git pull --prune --dry-run
|
This will show you which branches on remote can be removed, we will use this list to clean our local repo. The –dry-run flag makes the command just display what will happen if we prune the remote repo.
Read More...
After editing your config file (probably ~/.tmux.conf) you don’t need to kill your tmux server and reload it, you can just go to tmux command mode and source your configfile:
1
| <C-b>:source-file ~/.tmux
|
When you open use vim on tmux you might lose your colours that is because the term that tmux uses is screen and you might be using xterm, you can fix that by:
Adding to your alias(on your .bashrc .bash_profile or where every your alias are located):
Read More...
I prefer to keep all my gems separated by project so I use rbenv-gemset you might want to do that too.
If you want to use a specific ruby version on a project do the following:
1
2
| cd project
rbenv install 2.4.1 # you can pick any version `rbenv install -l`
|
then use that specif ruby-version on the project
This will create a .ruby-version file that contains the version you are using, to verify that you can check the version running:
Read More...
If you have to reference multiple directories on your ctags do the following.
Generate CTags for all of your projects, from your project’s root
this will generate a file tags, add it to the git ignore
1
| echo "tags" >> ~/.gitignore_global
|
Now configure your vimrc to search current dir, then add other the tag files from your other projects
set tags=./tags,$HOME/project1/tags,$DEVPATH/project2/tags
Now you can go to the root of all of your projects open vim and Ctrl-] Ctrl-t all you like
Read More...