The usual workflow while you are inside a branch is "make local changes and commit them to LOCAL REPO".
The Idea is that you work until you get something done (done => compilable, possibly with some tests testing the new functionality, in other words a FEATURE)
It is good idea to never commit code that cannot be compiled and also that you do from time to time a pull to reduce as soon as possible merging conflicts
STAGE&COMMIT: Aplly local changes to local repo (those are NOT yet sent to the server)
goal: document developing process without sending broken (Work in progress) code to server
PULL: Get changes from a branch into working copyGITHUB-GUI: select "changes at top" it will show a list of changes made by you, you can select wich files commit and do that with a comment
TORTOISE-GIT: right-click on folder-> commit (then select files, press "OK", usual stuff)
GIT: git add <file> (basically you are selecting a file for the commit, repeat for each file)
git commit (you are sending all SELECT files to local repo: just use "git commit -a" to select all changed files)
goal :A git pull is what you would do to bring a local branch up-to-date with its remote version (detect changes by other people early by doing PULL periodically so that you can quickly resolve conflicts into your local branh)
PUSH: Get changes from a branch into working copyTORTOISE-GIT: right-click on folder->TortoiseGit-> pull
GIT: git pull
goal: send local repo to the server. It finally makes visible to other people your changes on your branch, also they will see the previous history of your commits
PULL&PUSH
TORTOISE-GIT: right-click on folder->TortoiseGit-> push
GIT: git push
PULL REQUESTGITHUB-GUII: this is a peculiarity of github gui instead of pulling and pushing, you just press "SYNC" and a background job will be runned once. (same as calling pull followed by push except that if you made no changes push will not be runned ^^)
This is where GIT really shines and is differente from mercurial:
This is most usefull in opensource projects:
You basically create a branch that is peer-reviewed before becoming merged to master branch,
_________________
BRANCHING
For now I link to this GUIDE
I hope I'm back soon to maintain these thread as it deserves:D
_________________
possible branch strategies
Note that different files systems threaths uppercase differently, it is highly suggested that all branchnames are lower case
Branching strategies depends mostly on wanted management: Do you want mostly strict rules for deployment in a development with pre-fixed phases, or do you want to stay agile?
Most projects have at least 2 branches
- master
- develop
develop: sometimes shortened as "dev" is the main branch where most features are pushed/pulled on a daily basis
Hotfixes: some teams use a specific hoftix branch to do necessary fixes for master, those fixes are hacks and intended to stabilize a build and are usually short-lived. The real fix will happens inside dev (after having added test cases for that) with proper thought and design), the hotfixes should be on a separated branch to avoid polluting master with hackish code. So basically for each master build there may be 1 hotfix branch (If you have 4 builds in example your hotfix branches are <= 4)-
features: when you work alone on a feature your current local repo is the branch already, and will be merge when you pull/push. If you are working on a team then there could be a branch for that, usually branches should live short enough because having them opened for long is a problem.
when develop is not enough: If there are thousand people committing continuosly (there are reasons for doing small commits, but there are also reason for keep fewer commits), it is likely you will never be able to pull/push (becaues in the time you pulled someone else pushed and you have to pull again before pushing, it could also be a endless chain).
long living branches: are to be used if and only if there is a good reason for that, and there should be at least 1/2 team members that are very confident with GIT to repair eventual problems. Even a 3/4 days branch can become a problem if team is committing very fast and regularly.
The alternative to hotfixes is to do releases on separate branches, the problem with that is that usually there's much more effort into the release than in continuing the roject.
A example of a long living branch: You are developing a new framework for your project => that will require to change everything, then you start doing the framework and once it is done you can start refactoring existing code (keeping it in a branch avoid to start a new repository just for that, which is anyway an alternative).
When framework is ready we merge develop branch into the longliving branch and start the refactoring, there should be some discipline in the team (in example every new feature on develop should be merged back also in the long living branch etc.), when finally it is finished you can merge the long living branch again in develop.
________________
After you have some basics you have to
TRY GIT <-- LINK
enjoy!
, however GIT is no better than Mercurial, both are equivalent. The difference is in the tools/websites support for one of the 2 protocols, in example in Github you have the pull request feature that allows to automatically merge a external change only after approval, for doing the same in SVN you should create a patch (manually creating the .diff file), and someone with write access should review (apply the .diff manually) it before committing.
good to know you like GIT (which I'm using too).