Hahaha! the lazy ass is back! This time its git time.
Hey folks! Long time no see - this seems to be the norm now; I have gotten used to it. Its not much of a rant today, I am all praise for Git and the git provider GitHub. I use git on a daily basis for my work (you should too, if you work anything that needs versioning, not just code stuff; you can start off here!); we have a git repository set up which (almost, well close to almost :-P) mimics the functionalities of GitHub. I am pretty happy how it has helped us in our work (minus some cranks that are strictly not due to git itself). We generally use git similar to svn (I know it is a crime!) i.e., have a central repository and clone off it, every time we have to do some changes, each of us pull the changes -> make edits -> commit and push. I guess we adapt this work flow to avoid learning/remembering all the commands that we need if we use git as a true distributed version control system.However, if we are working on a multi-people project each working at his(her) own convenience, we need to get out of the comfort zone of "simple git usage".
The first thing we need to do is adopt a process (yeah! you heard it right, process - the thing we students dread/despise/deplore/detest process; but, well it helps!). It doesn't have to be anything fancy. Some simple steps like the ones below is sufficient. (Be warned: This may be too watered down for your need, if you are doing more complex stuff, the complexity increases.)
Whew! that wasn't so long, was it? ;-)
Until next time... adios!
Hey folks! Long time no see - this seems to be the norm now; I have gotten used to it. Its not much of a rant today, I am all praise for Git and the git provider GitHub. I use git on a daily basis for my work (you should too, if you work anything that needs versioning, not just code stuff; you can start off here!); we have a git repository set up which (almost, well close to almost :-P) mimics the functionalities of GitHub. I am pretty happy how it has helped us in our work (minus some cranks that are strictly not due to git itself). We generally use git similar to svn (I know it is a crime!) i.e., have a central repository and clone off it, every time we have to do some changes, each of us pull the changes -> make edits -> commit and push. I guess we adapt this work flow to avoid learning/remembering all the commands that we need if we use git as a true distributed version control system.However, if we are working on a multi-people project each working at his(her) own convenience, we need to get out of the comfort zone of "simple git usage".
The first thing we need to do is adopt a process (yeah! you heard it right, process - the thing we students dread/despise/deplore/detest process; but, well it helps!). It doesn't have to be anything fancy. Some simple steps like the ones below is sufficient. (Be warned: This may be too watered down for your need, if you are doing more complex stuff, the complexity increases.)
- First, create a main repository for the work that you are starting (or go to the appropriate step below as necessary).
- Fork it.
- Clone the fork to your workstation.
- Branch it out for the particular content you want to add/modify.
- Do the work; implement new things, add new content, modify existing stuff ... what ever you want to do! Don't forget to test out your contributions!
- Commit and push the new content.
- Create a pull request for merging the new content to the main repository.
- If you already have some work that needs to be put in the main repository, you need to do some more work.
- First, you need to add the main repository to your remote site like this.
- Next, you need to sync the copy on your workstation with the ORIGINAL remote (let us call it upstream). You can use git pull or git fetch to get the upstream changes.
- Merge changes from your copy (or branch) to the upstream changes you just fetched.
- Push your changes to your fork (presumably on GitHub) and then create a pull request.
Whew! that wasn't so long, was it? ;-)
Until next time... adios!
