While I have coded on the past with SVN for a long time and lead a team working on a central SVN server, I have never really coded on Git.
While I understand the main conceptual differences between the SVN and GIT, and especially recognize the great productivity we get working with a SAAS platforms such as Github, (As my team is doing), I decided to spend some deeper time reading a book and some videos to get into the details and getting a deeper understanding of it.
Here are some notes after reading Git PRO and watching some videos on Github.
-- Git is fully decentralized.
Each one needs to create or clone a repository on his own machine, no need to have access to a server to work on git:
cd /your/code/ //cd to the directory where you have your code
git init
git add . // add all the files on this directory to the first commit
git commit -m "first commit"
You create your repo on your own machine, you commit on it, nobody knows until you push your code to another "shared repository"
-- Git has a Staging concept.
git add // not only when you create a new file, but also each time you modify one.
This is a concept of staging on git, "git add" meanings adding to your new commit.
You can use
git status //to check if you have file that are "untracked"
-- You do everything with Branches, they are at the core of the Git concept.
Branches are very lightweight in Git, and it is part of the concept to create a Branch for whatever feature or fix you will be working on, the smaller the better.
Branches are isolated and you can start many of them to work on different features, when you decide to go into production, you won't be affected by all the branches that are not yet ready, as they will stay aside the "master" branch, which is the only one that should be always in "ready for production" state.
1. The common process is:
--- A --- create a branch and switch to it
git branch feature123 // create a new branch
git checkout feature123 // move into the branch
>> Git checkout will change your current working directory to the branch you are working, files in your directory may disappear if they doesn't exist in the branch).
Note: git branch without any parameter lists all the available branches in your repo.
--- B --- commit on it
git add xxxx
git commit -m "xxx"
--- C --- merge your branch to the master
git checkout master
// you must be on the "main branch" to be able to merge with any "feature branch"
git merge feature123
If the merge has any conflict, you can try to check the differences between origin and source with:
git mergetool.
To resolve the conflict after a failed merge, you need to modify one of the two files, and do a
"git add" to all the files that have a conflict.
then:
git commit -m "" // to commit the merge
--- D --- delete the branch
once you're done with the feature, you don't need the branch any more,
git branch -d feature123
2. The process of working with a remote repo on GitHub
git clone https://github...my-new-repo
check the clone url displaid on your google account after you created the repo. Once you cloned the repo, it will be available as a "remote repository", then you can continue coding on your machine and regularly push your code to your github "remote repository". (after committing your code locally).
git push // publish the code you committed locally to your remote repo on github
If there are more than you working on the same repos, you can check if there is no modification on the remote repo by pulling the code.
git pull // get the new work that have been pushed on my remote repo by other devs
3. The process of working on an external project on gitHub
On most of opensource official github repo, they don't offer anyone to push code directly on the official repository.
Instead, the process is inverted: you will copy the entire project code as one of your own repositories.
(This is called Forking). Then you will work on it locally, committing and pushing to it regularly.
Once you have a finalized feature to suggest to the original projet, you can send a Pull Request:
Basically, you're asking the creator of the project to look at your code, and to validate the merge on the original repository (he is managing).
Once you worked and finalized a commit on a branch, you can push it to your github repository.
Then from github you can add a PullRequest so that is can be reviewed and then later merged on the "master" branch.
4. Repos inside repos
Sometimes we need to clone a repo inside another repo, for exemple to install a foreign library.
For this to happen we use:
git submodule add git://github.com/jquery/jquery.git
This will add a new repository inside a working one. It will permit being able to pull any new version from git, while not being considered in the main repo.
Check this page to know more:
http://www.arlocarreon.com/blog/git/git-repo-inside-a-git-repo/
While I understand the main conceptual differences between the SVN and GIT, and especially recognize the great productivity we get working with a SAAS platforms such as Github, (As my team is doing), I decided to spend some deeper time reading a book and some videos to get into the details and getting a deeper understanding of it.
Here are some notes after reading Git PRO and watching some videos on Github.
-- Git is fully decentralized.
Each one needs to create or clone a repository on his own machine, no need to have access to a server to work on git:
cd /your/code/ //cd to the directory where you have your code
git init
git add . // add all the files on this directory to the first commit
git commit -m "first commit"
You create your repo on your own machine, you commit on it, nobody knows until you push your code to another "shared repository"
-- Git has a Staging concept.
git add // not only when you create a new file, but also each time you modify one.
This is a concept of staging on git, "git add" meanings adding to your new commit.
You can use
git status //to check if you have file that are "untracked"
-- You do everything with Branches, they are at the core of the Git concept.
Branches are very lightweight in Git, and it is part of the concept to create a Branch for whatever feature or fix you will be working on, the smaller the better.
Branches are isolated and you can start many of them to work on different features, when you decide to go into production, you won't be affected by all the branches that are not yet ready, as they will stay aside the "master" branch, which is the only one that should be always in "ready for production" state.
1. The common process is:
--- A --- create a branch and switch to it
git branch feature123 // create a new branch
git checkout feature123 // move into the branch
>> Git checkout will change your current working directory to the branch you are working, files in your directory may disappear if they doesn't exist in the branch).
Note: git branch without any parameter lists all the available branches in your repo.
--- B --- commit on it
git add xxxx
git commit -m "xxx"
--- C --- merge your branch to the master
git checkout master
// you must be on the "main branch" to be able to merge with any "feature branch"
git merge feature123
If the merge has any conflict, you can try to check the differences between origin and source with:
git mergetool.
To resolve the conflict after a failed merge, you need to modify one of the two files, and do a
"git add" to all the files that have a conflict.
then:
git commit -m "" // to commit the merge
--- D --- delete the branch
once you're done with the feature, you don't need the branch any more,
git branch -d feature123
2. The process of working with a remote repo on GitHub
git clone https://github...my-new-repo
check the clone url displaid on your google account after you created the repo. Once you cloned the repo, it will be available as a "remote repository", then you can continue coding on your machine and regularly push your code to your github "remote repository". (after committing your code locally).
git push // publish the code you committed locally to your remote repo on github
If there are more than you working on the same repos, you can check if there is no modification on the remote repo by pulling the code.
git pull // get the new work that have been pushed on my remote repo by other devs
3. The process of working on an external project on gitHub
On most of opensource official github repo, they don't offer anyone to push code directly on the official repository.
Instead, the process is inverted: you will copy the entire project code as one of your own repositories.
(This is called Forking). Then you will work on it locally, committing and pushing to it regularly.
Once you have a finalized feature to suggest to the original projet, you can send a Pull Request:
Basically, you're asking the creator of the project to look at your code, and to validate the merge on the original repository (he is managing).
Once you worked and finalized a commit on a branch, you can push it to your github repository.
Then from github you can add a PullRequest so that is can be reviewed and then later merged on the "master" branch.
4. Repos inside repos
Sometimes we need to clone a repo inside another repo, for exemple to install a foreign library.
For this to happen we use:
git submodule add git://github.com/jquery/jquery.git
This will add a new repository inside a working one. It will permit being able to pull any new version from git, while not being considered in the main repo.
Check this page to know more:
http://www.arlocarreon.com/blog/git/git-repo-inside-a-git-repo/
Commentaires
Enregistrer un commentaire
Tell me what you think