# GIT - Edit

⚠️ 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
  • 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 push your 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