4 posts tagged with "git"

So, no need to tell it anymore, I'm doing everything in Docker containers even coding (since I'm coding using devcontainers) but ... till now, I was using git on my host only.

I mean, I need git on my host because I should be able to clone a repository. But the question is: should I use git from my host except for git clone? Can I work in my container and from there do actions like a git push?

My current workflow is: from my host, I'm cloning a repo on my disk then I build Docker image(s), run container(s) and jump in it (like starting my devcontainer). I start too a console in my container to start processes, work on files, ...

From time to time, I push my changes to my versioning system (like Gitlab/GitHub) and here is the point: I need to exit my devcontainer (or use another console), go back to my host and run, from my host, commands like git add . && git commit -m "feat: The great feature I'm working on it" && git push.

Let's see how to improve this process and be able to run git commands from inside our container.

You like clean code, don't you? And you hate getting an email from your versioning tool (e.g. Github or GitLab) telling you that your last commit didn't go through, that the formatting of your code is bad; this is because you've left one space too many at the end of a line or you've used single quote instead of double (or the opposite), for example.

You've pushed your changes, already start to work on another activity, perhaps another project and boum, two hours after your last commit (because the CI server was working on a lot of pipelines before yours), boum, you get a Your last commit has failed, #gnagnagna. I hate it as much as I love clean code.

So, what should we do to avoid this?

The answer is simple! Before each push, we should run the same code analysis tools that are executed in the CI, i.e. phplint, php-cs-fixer, phpcbf, phan, phpstan, ... (for PHP) or pylint, mypy, prospector, black, ruff, ... (for Python) or shellcheck and shellformat (for Linux Bash) or ...

We should, but do we think about it every time? Unfortunately not.

Let's see how to correct this.

In this article, we're going to explore some tips for using Git more easily by customising the ~/.gitconfig file.

We'll create a new git undo command to abandon the last local commit.

We'll see how to share Windows Credentials manager with Linux, to have multiple credentials based on your folders structure, ...

We'll also see how to better works with branches like sorting them by commit date instead of their name, to automatically prune (remove) old branches or to force the creation of a new branch on the remote.

There are plenty articles on the Internet but I didn't find the one that allowed me, without an impressive amount of trial and error, to find the solution.

So here's another article to add to the long list: how to access a private project stored at Github when creating a Docker image. In other words, the SSH key is not stored in the image. Docker will just use your key when executing the project recovery layer (the one containing the git clone instruction) and will not keep track of the key afterwards.