I have been using various version control tools for years, however it has taken me a long time to make version control a core part of my work process. All of the ideas in this post come from other people... so as usual I am indebted to my colleagues for making me a more productive coder.
I now generally create a repo in my remote master, and then push the initial commit. This requires running the following on you local machine.
If you want other people to work with you, then they can now clone the project.
Now for the interesting part: when you want to commit something into the repo but your branch has diverged from master. You can of course just run git pull and it will merge the results, unless there are drastic conflicts you need to resolve. But this creates a non-linear commit lineage, you can't look at this list of commits as one single history. To get a linear commit history you need to do the following.
This will rewind your commit history to what it was before the changes in master were applied. It will apply the changes from the master branch, and then apply your sequence of changes on top. Voila, linear commit history.
There are a number of other key ideas in effectively using git.
Branching can be a scary experience the first time you do it. However, if you want to do major refactorizations of code that is in production and needs to be supported while those changes are being made, then this is the only way to do it. In fact I don't know how people did these before tools like git.
Create a branch and check it out in a single command
When you are done go back to your branch
If you changed things in the master that you need inside your refactorization work, then merge master into it:
Once you are done with all of your changes, run your tests etc, then your can merge that branch back into your production code.
I now generally create a repo in my remote master, and then push the initial commit. This requires running the following on you local machine.
git init
git add *
git commit -m "Initial Commit"
git remote add origin git@remote.com:project.git
git push -u origin master
If you want other people to work with you, then they can now clone the project.
git clone git@remote.com:project.git
Now for the interesting part: when you want to commit something into the repo but your branch has diverged from master. You can of course just run git pull and it will merge the results, unless there are drastic conflicts you need to resolve. But this creates a non-linear commit lineage, you can't look at this list of commits as one single history. To get a linear commit history you need to do the following.
git fetct
git rebase
This will rewind your commit history to what it was before the changes in master were applied. It will apply the changes from the master branch, and then apply your sequence of changes on top. Voila, linear commit history.
There are a number of other key ideas in effectively using git.
Tag your releases
This is pretty simple, every time I push a major piece of code to production, release an App on the App Store etc, then I make sure to tag the contents of the repository. So that release can be recovered with minimal stuffing around.git tag -a v1.2 -m 'Version 1.2 - Better than Version 1.1'
Create Branches
Branching can be a scary experience the first time you do it. However, if you want to do major refactorizations of code that is in production and needs to be supported while those changes are being made, then this is the only way to do it. In fact I don't know how people did these before tools like git.
Create a branch and check it out in a single command
git checkout -b refactor
Go back to master if you need to patch something quickly
git checkout master
When you are done go back to your branch
git checkout refactor
If you changed things in the master that you need inside your refactorization work, then merge master into it:
git merge master
Once you are done with all of your changes, run your tests etc, then your can merge that branch back into your production code.
git checkout master
git merge refactor
Once it is all merged and deployed, you don't need the branch so delete it.
git branch -d refactor
No comments:
Post a Comment