⚠️ Launch all git commands outside the box, if you are ssh connected on your VM, simply type :
exit
Initialize your repo on GIT
Verify that there are no .git folders in your project root dir (/httpdocs) and neither on your theme dir (/httpdocs/src/theme/YOUR_THEME)
If there is any, delete them.
First, create a new repository on your Bitbucket account.
(Magina : Define your new project with Magina_fr as the owner so all team member can access to it)
Init your repo : the normal way
When creating a new git repo, here is the process to make your first commit :
git init
git add .
git commit -m "initial commit"
git remote add origin git@bitbucket.org:magina_fr/YOUR_REPO.git
git push origin master
Init your repo : the unconventionnal but working way
- Create a new temporary folder anywhere on your computer
- Clone your new empty repo in this temporary folder
- Copy the .git folder, and paste it on your project root path (/httpdocs)
- Verify that everything is correct :
git remote -v - Make your first commit :
git add --all git commit -m "initial commit" git push
Teamwork
For our bigger websites, we may need to have multiple developers working on the project at the same time.
Please follow the following process :
Workflow
- You should have at least two branches : master and staging (or preprod)
- When a developer starts working on a new feature/bug, he checks out the staging (or preprod) branch.
He then creates a new branch locally with the name of the bug or feature he is working on :git pull staging git checkout -b feature/name-of-your-feature - When the developer is done working, he needs to push his new branch on bitbucket and then creates a pull request for his branch.
*Important : Before you push your branch, you need to do what is called a « git-rebase », it gets and applies (in the right order) all the commits that were pushed to the staging (or preprod) branch while you were working on your own branch.git fetch git rebase origin/staging - You can now
git pushyour new branch and create the pull request on bitbucket.org admin.
The « main » developer of the project can now merge the pull request with the staging (or preprod) branch when needed.
When a new version of the project is ready for release, you can merge the staging (or preprod) branch with the master branch.
The full process :
┌────────────────────┐
↓ │
┌─staging │ # → checkout staging
│ ├── feature/my-branch │ # → create your own branch
│ │ ├── commits │ # → work on your own branch
│ │ ├── rebase │ # → git rebase with staging
│ │ ├── push │ # → push your branch to bitbucket
│ │ └── pull request ──┘ # → pull request to staging
│ │
│ └── master
│ ↑
└───────┘ # → merge staging with master
Made a mistake while pushing on Git ? ?
Don’t worry if you accidently pushed a commit on the wrong repository, you can easily revert your changes ?
Search on the concerned Bitbucket repo, the ID of the last good commit. (you can copy it from the Commits tabs (Modifications)) ;
Type git revert « Good_commit_id », (optionnally verify that everything is correct, and re-push)
⚠️ Note : The revert may delete folders/files on your local project : perhaps save globally the impacted files to not loose your work !
git revert XXXXXX
(git status : check that everything is ok : must display that your branch is ahead by 1 commit )
(git remote -v : check that you continue to push on the wrong repository to cancel your changes)
git push
Tips : No more warnings "CRLF will be replaced by LF in file."
You can adjust your git config to not show anymore this warning for each file :
git config --global core.autocrlf false