Git is the answer to all the above needs. Git is a distributed version control system:
There are many options for hosting your central repository; we are recommending Bitbucket since it is free and private.
git push -u origin masteryou will need to enter the password for your Bitbucket account at the prompt. (You can set up an ssh key if you want to avoid doing this every time - see the BitBucket tutorial for help on this.) Note you need to add a file before the commit/push will work.
addfiles to the staging area,
pushthem to your teammates,
pullchanges made by your teammates, etc. See the following section for details.
Before using git, you need to tell it who you are. You should only have to do this once on each account that you will use to store local clones. On some systems, you may get a warning if you fail to do this; on others, it may be an outright error that prevents you from commiting your changes. To fix this, use the following two commands, substituting your own name and e-mail address for the placeholders:
git config --global user.name "Your Name"
git config --global user.email firstname.lastname@example.org
After this, you can use the following git commands to manipulate your repository. Note you need to be within the directory tree of your project repository for these commands to work. (See below for creating a repository by initializing an existing project directory.)
git add newfile.c
git commitand it will automatically
addall the files that changed since your last revision. It won't add new files, only changed files.
git commit -m "Just started writing newfile.c"
-aoption as well:
git commit -a -m "changed output routine"-- it will automatically commit all files changed.
error: failed to push some refs to 'https://email@example.com/myteam44/myrepo44.git': this means you need to first
git pullchanges by your team-mates before committing. It only happens if a team-mate changed a file you also changed.
commitalone will not let your teammates see your changes, you need to
git push -u origin master- this pushes your (local) master (main) branch to
origin, the remote server. Subsequent pushes will by default go to the same branch and remote so you can leave
CONFLICTerror message; see Resolving Conflicts below on how to deal with that.
git pull. You could get a
CONFLICThere, see Resolving Conflicts below on how to deal with that.
git remote add origin https://blah...blah(the initial BitBucket setup instructions include this)
git checkout thatfileyoujustscrewedup
git status- shows whether git is tracking them and if there is a change not yet commmitted to that file.
originusually if hooked to one remote)
git branch -a. It probably will reply only
* master remotes/origin/masterwhich means you are on the master branch and that is in fact the only branch, but if there are other branches you will see them.
git initfrom inside the (likely new) directory where you want your repository to be. It creates a hidden .git folder, use
ls -ato show it.
git init. Go to the directory in which you want the repository to appear (as a subdirectory) and type
git clone https://bitbucket.org/username/myrepo.git(filling in the appropriate information on your repo)
git clone /home/fr34/code/thisrepo/
What if two team members accidentally overlap on a change to a file? Note that changes to different lines of the same file will automatically be merged, so the only serious conflicts happen when one person commits a change to a line where a previous commit had changed.
myfile.txt, the other wants to say "Howdy, world!"
commitfirst and pushes. Now Goodbye changes the same line. Goodbye's
commitwill go through, but upon
pushGoodbye will get something like
CONFLICT (content): Merge conflict in myfile.txt
myfile.txtnow, Goodbye will see something like
<<<<<<< HEAD Howdy, world! ======= Goodbye World! >>>>>>> c0ebf4a3d93ee7288c6c6f216e69e7b019a1f27fThe
========lines are Howdy's, and the
>>>>>>>are Goodbye's lines. These lines are around each place there is a conflict, make sure to look through the whole file.
pushit to get the remote repository back in sync.
You should make repository-using as easy as possible for the other people you're working with by only pushing code that compiles. It is also good practice to agree to a common coding style and only push code that has been style checked.
The above covers only the most basic git features. You can also
branch off a new version, just
fetch changes without also merging explictly,
rebase your changes over the remote changes,
stash a particular state,
tag a commit with a label to find it later, etc. Ouch, I'm getting a headache from all these options!