Blog - Hướng dẫn, Training Data
Understanding git at Vatico
1. Fundamental Concepts
Git is a powerful tool for version control, which is essential for managing changes to code over time. At Vatico, we focus on two key dimensions to leverage Git effectively:
- Branches: Branching in Git allows developers to diverge from the main line of development and work independently. This is crucial for experimenting with new features without affecting the main codebase. Each feature at Vatico is developed in its own branch, ensuring isolated environments for each change.
- Remote vs. Local Repositories:
- Remote Repository: This is hosted on a server (at Vatico, we use GitLab). It serves as the central hub where all changes are eventually pushed and from where they are fetched.
- Local Repository: This is a developer’s personal copy of the project, residing on their computer. It allows developers to work offline and commit changes locally before syncing with the remote repository.
To ensure smooth merges and minimise conflicts:
- Keep Local Branch Up-to-Date: Regularly update your local branch with the latest changes from the remote repository. This practice reduces the chances of conflicts when you merge your changes back to the remote repository.
- Consistent Synchronisation: Continuously push your local changes to the remote repository to keep both synchronised. This habit prevents scenarios where the local and remote repositories diverge significantly, which can complicate merging and collaboration.
2. Branch Methodology at Vatico
- Continuous Deployment (CD): Each feature branch is expected to be fully functional and tested before it is merged. We practise continuous deployment, which means that as soon as a feature is ready and merged, it is deployed to production. This approach emphasises the importance of thorough testing.
- Testing: There are no designated development or production branches at Vatican; instead, each feature branch must be tested rigorously. Although we previously had a CI/CD pipeline, it has been discontinued. It’s now imperative that developers ensure their features pass all tests in the SQL environment before they request a merge.
This methodology promotes a high degree of responsibility among developers to maintain the integrity and stability of the codebase. Each member of the team is expected to ensure that their contributions do not disrupt the existing system and that any new features integrate seamlessly with the existing infrastructure.
3. Git command
How to name branch
DA-<Ticket Number>-Description: for report
DE-<Ticket Number>-Description: for vatico-fulfillment
How to update local branch to remote changes
- git checkout main (checkout to main/master branch)
- git status (check for upstream updates)
- git pull (pull upstream)
How to create new branch
- git checkout main
- git pull
- git checkout -b <branch-name>
How to commit change
- Run tests to ensure your commit is bug-free
- git status (check current changes)
- git add . (to stage changes all) OR git add <file_path> (to stage change a specific file)
- git commit -m <commit-message> (to create a commit with staged changes)
How to push upstream
- Run tests
- git push –set-upstream origin <branch-name>
How to create a PR
- PR title
- Commit message, edit it to make it even clearer the changes you’ve done
- Assign reviewer (usually the Data Engineer that’s in charge of your function)
- Assign to myself usually. If you’ve done this PR on the behalf of someone else, you can assign it to them
- Final step: Press ‘Create pull request’. Once merged to main, table will appear in all dbs
Note: Do not have too many changes in 1 PR.
How to rebase into your branch
Assuming you are currently on your branch
Step 1: Pull the latest main branch
git checkout main
git pull
Step 2: Rebase
git checkout <your branch>
git rebase -i main
An error of conflict may appear if you are adding multiple things to the same file on multiple PRs. Go to your editor and resolve the conflicts there by opening the file that has the merge conflict (check which files with git status, cmd+p to go to these files):
git status to check which files have been changed (in red)
Stage changes
git add <file name> OR gaa
git rebase –continue then save quit
git push –force-with-lease OR gpf
How to change in PR by someone’s else
Do following command
$ gco <branch>
$ git reset –hard origin/<branch>
If you instead have some changes made in the web editor that you want to pull to local, the following (similar to the above) will COMPLETELY remove your local in favour of the remote branch which is ahead.
git branch -lvv -show remote of your local branches. You will need the equivalent of origin/Your-branch to reset your local branch to the remote!
Next, to reset your local branch to the remote, destroying all local changes in favour of the remote origin in case if you resolved merge conflicts in the web editor:
git fetch –all
git reset –hard origin/ADT-your_branch
git pull
