Git in a client's repo: identity, remotes, credentials and review rules

Picture your first week on site at a bank. You are handed a laptop that blocks software installs, an account on the bank’s internal GitLab, and a repository with a dozen branches named after different branch offices.

By Wednesday afternoon your first merge request is stuck because the Merge button is locked. Meanwhile, the commit history shows your personal email sitting next to the client’s corporate addresses.

None of this is technically hard. But mistakes like these erode a client’s trust faster than a bug does, because they show you have not yet understood their environment.

For an FDE, Git on a client site is an operational skill made up of five tasks: installing it on a machine that is not yours, keeping your identity correct, managing several remotes, keeping credentials safe, and respecting the client’s review rules.

The client’s machine, the client’s rules

The first job is getting Git to run. Pro Git says that on Debian-based Linux distributions such as Ubuntu you use apt. On macOS Mavericks (10.9) and later, typing git in Terminal for the first time prompts the machine to install the Xcode Command Line Tools.

Windows is where people get stuck. The official build comes from Git for Windows, a project separate from Git itself, while the Chocolatey package is maintained by the community. On a locked-down client VM, ask IT which sources are approved before downloading anything, because installing from the wrong source can turn into a security ticket.

If the client’s operating system ships with a very old version of Git, Pro Git notes that installing from source gets you the latest release. Treat this as a last resort, to be used only if the client allows builds on their machines.

One folder, one identity

The most common mistake among people working for several clients is committing with a global user.email. The git config documentation describes exactly this situation: you can use a different user.name and user.email depending on the directory that holds the worktree, through includeIf with a gitdir condition.

The simplest structure is one folder per client. In ~/.gitconfig:

[user]
    name = Nguyen Van A
    email = [email protected]

[includeIf "gitdir:~/clients/nganhang/"]
    path = ~/clients/nganhang/.gitconfig

And in ~/clients/nganhang/.gitconfig:

[user]
    email = [email protected]

(Here nganhang means “bank” and congty-cua-ban means “your company”.) Every repository under ~/clients/nganhang/ now automatically uses the email the client issued. To check, cd into a repo inside that folder and run git config user.email. The git config documentation uses this very type of condition to apply one configuration to every repository inside a directory, so you only need to declare it once per client.

Whose origin is it?

When you clone from the client’s GitLab, the default remote is called origin. A few weeks later you add an internal repository from your own company to hold shared integration code, and origin starts to become ambiguous. Rename it from the start:

git remote rename origin nganhang
git remote add noibo [email protected]:fde/connector.git
git fetch noibo
git branch -r

According to the git remote documentation, rename also updates all remote-tracking branches and related configuration, so there is nothing to fix by hand. After git fetch noibo (where noibo means “internal”), branches appear as noibo/feature-x, clearly separate from nganhang/feature-x.

The Git documentation offers another piece of advice worth remembering: if you fetch from one place and push to another, use two separate remotes. On a client site, this rule prevents the worst-case scenario of pushing the client’s code to your company’s server, or the other way round. Before every push, name the remote explicitly (git push nganhang feature/x) rather than letting Git guess.

In a repository with many branches for different offices or sub-clients, clear remote names make git branch -r read like a map. The prefix alone tells you who each branch belongs to.

Where does your password live on someone else’s machine?

By default Git does not store credentials, so every HTTPS push asks you to type them again. The natural reflex is to enable the store helper, and on a client’s machine that is a mistake. Pro Git is explicit: store mode saves credentials to a plain-text file on disk, and they never expire.

On a laptop or VM the client owns, especially a shared one, such a file is a security hole with your name on it. A better choice is the cache helper, which keeps credentials in memory and clears them after 15 minutes:

git config --global credential.helper cache

Re-entering credentials after every long break is a minor nuisance, but far cheaper than a security investigation. If the client has its own token policy, follow it.

Read the review rules before writing code

Back to that locked merge request. On GitLab, a client can enable required approvals: according to the GitLab documentation, a merge request cannot be merged until it has enough approvals from the designated people. This is not a bug. It is their process.

The question is who has to approve. GitLab uses a CODEOWNERS file to assign reviewers file by file. If one merge request touches both the payments directory and the reporting directory, you probably need two different groups to sign off, and your MR will wait for the slower of the two.

So before creating a branch, open CODEOWNERS and find the lines that match the paths you plan to touch. Split your changes so that each merge request needs only one owner group, and send that group a short note in advance about what is coming. A small MR, sent to the right people and flagged ahead of time, usually moves faster than a large one that lands in the inboxes of three teams.

The mistakes that keep recurring

The most common is committing to a client repo with a personal email, which includeIf fixes if you set it up before your first line of code. Next is leaving everything named origin and then pushing to the wrong server. Then comes enabling store on a shared machine to avoid retyping a password.

The last is harder to spot: treating the client’s review process as an obstacle and looking for a way round it. Approvals and CODEOWNERS tell you who actually owns that code, which means they point to the people you need to get to know early.

If you are preparing a CV for an FDE role, replace “proficient in Git” with something specific: “worked on a client’s internal GitLab with required approvals and CODEOWNERS, managing multiple remotes and per-client identities”. Have a short example ready for interviews about a time you split an MR by owner group.

On a client site the repository is not yours, but every commit still carries your name. Getting the setup right on day one is the cheapest way to keep that signature trustworthy.