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

> On your first day at a client site, the Git mistake to fear is usually not a merge conflict. It is a commit with the wrong email pushed to the wrong server.

Bản gốc: https://fdetimes.net/en/guides/git-setup-client-repo-fde/

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`:

```ini
[user]
name = Nguyen Van A
email = a@congty-cua-ban.vn

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

And in `~/clients/nganhang/.gitconfig`:

```ini
[user]
email = a.nguyen@nganhang-noibo.vn
```

(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.

**Điểm mấu chốt:** Do not rely on memory to switch email before every commit; let the folder structure do it for you.

## 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:

```bash
git remote rename origin nganhang
git remote add noibo git@git.congty-cua-ban.vn: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:

```bash
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.

**Thử ngay tuần này:**

- Create a ~/clients/ folder and a separate .gitconfig for an imaginary client, link it with includeIf, then run git config user.email inside and outside that folder to check it works.
- In a personal repository, rename origin to a client name with git remote rename, add a second remote, then run git branch -r to see the remote-tracking branches.
- Open any GitLab repository that has a CODEOWNERS file and, before creating a branch, list who has to review the directory you plan to change.

## Nguồn

- [Git - Installing Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)

- [Git - git-remote Documentation](https://git-scm.com/docs/git-remote)

- [Merge request approvals (GitLab Docs)](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)

- [Git - Credential Storage](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage)

- [Git - git-config Documentation](https://git-scm.com/docs/git-config)