 Hi everyone, my name is Sayani, so you can go to this website and find out my contacts. I also happen to do a little site project of mine, which is called WeBuildSG. So how many of you are at a developer meetup in Singapore for the first time? Awesome! So do you want to find out more? Not you, Justin. Yes. Alright, so if you are looking for any programming language, whether it's hardware, software, what we do here is we query even bright API, meetup.com API, Facebook API, ICS URL, every hour it runs a cron job, and all the free developer meetup, engineering meetups are here. All beginners are welcome, all advanced people have income. Even if you're not a developer, you're welcome. So everybody's welcome, we're all a friendly community. Come and join us, including everyone. And here the open source is listed. So if you have put your location as Singapore, contains Singapore, not match Singapore. And you have a GitHub repository of more than 50 stars. Updated within the last three months, your GitHub repository will appear here. So go and add Singapore to your location and GitHub. And you see this mic here, taking photos, not sorry, videos of meetups. And we also aggregate the meetups from engineers.sd, so thanks to people like Mike. Okay, so that's a little bit about the developer community in Singapore. So I'm here to talk about Git for Teams, but this will not really be a talk, it will be a discussion, because it's for Teams. So how many of you currently use other version control systems other than Git? What do you use? Sorry? Oh, Pofos, okay. TFS subversion. Is this the right meetup to ask this question? Who uses only Git? Oh, you want to hear, okay, so what are the other monkey shell? SVN? What are some of the old ones? Great. So Git is a distributed version control system, so we're going to be talking about teams. It can be either internal team within your company, or it can be open source. So let's talk about the first one, branching. So how many of you have a branch like a... Do you have a feature branch? Do you always branch out when you work on a feature? How many of you do that? Or you just work on master branch? All right, great. And do you have a branch called Fix or something when you have a hot fix? All right, some of you and maybe a release branch. So how many of you use this branching model called Gitflow? All right, so some of you use it. So there was a blog post probably a few years ago, like in 2010 or 29, by this Dutch guy. And he came up with this branching model called Gitflow. I will release the slides in later so they can click it. And he basically talked about this pattern. So master branch is always deployable. So you see they are tagged and you always work on develop a branch. And then you branch up in feature and eventually you merge it to master, then are tagged. And in GitHub or if you kind of search in Google, Gitflow is actually a framework. So maybe I can show you guys in... So let's see ICD here. And you can actually do Gitflow in it. And then you can set up all these things. And guess what? If you list out all the Git branch, you see there's a master in the develop. So you'll always be in the develop. And then you can start with Git. I have some autocomplete Gitflow feature start. And then maybe you say git meetup. And right now you will see that there are three branches. So things like git checkout branch, git go to this branch and release it. They will all do it here. So I suggest if you have not checked out Gitflow, you can check it out. It can come useful for teams. And in open source world, how many of you have heard of the Git hub flow? A few of you. So how is it different? The Git hub flow works in the Git hub model. So instead of creating a develop branch and then the feature branch, you basically clone a repository and then you send a pull request. You work on a branch and then you send a pull request. So the master is like this and all you do is kind of really short circles back to the master. So they say this is much simpler. And I believe a lot of the open source developers use this model. And you can also do that. So if you want to send a patch, you use the Git hub flow. So once again, they do have a guide here by GitHub itself for the GitHub flow. A lot of people also do this within the company with private repositories as well. So basically you're never added as an organizer or collaborator. You always have a copy yourself and you keep pull requesting to the main repository. Okay, so this is something I heard just a few days ago actually. It's called GitPair. How many of you do peer programming? Awesome. Any of you use GitPair? You do. In fact, the developer who told me had been trained by Pivotal Labs or Neoware, Michael comes from. So GitPair actually allows you to set up... If I'm not wrong, Michael, you can feel free to contact me. You can actually set up both developers' identities, and then it allows you to work together. GitPair commit and GitPair release and so on and so forth. So I believe in terms of branching model, check out Gitflow, GitHubflow, GitPair. So is there anybody else who just works on the master and if something goes wrong, you just reset or something? All right, it happens as well, I'm sure. Okay, great. Next is a little bit about keeping your repository in sync with the main one. So the first thing I'll do is usually just git pull and make sure it's in sync. And the other thing I do is syncing up fork, especially for open source once again. I fork it and then I work again, make sure you kind of git fetch upstream to make sure that it is in sync with the real repository. How many of you use other methods to keep yourself in sync? I do want to hear more. GitPull, that's all? CJ, do you have any brilliant ideas? Brilliant? Yeah, brilliant ideas, no. Like, GitPull is mad? No, no. Are there anything else I'm missing? Someone probably uses the Mac client, it just gets to sync but it doesn't work. Yeah, Mac client, that's a good one. Probably I should talk about it. So how many of you work in Git in command line? Wow. Yeah, GUI, I would love to hear about a different type of GUI. What GUI do you use? The Mac client. Git Hub client? Git box. Git box? I'll git for you. Source tree, there's one more. I use the once upon a time git tower. Anybody else? So, alright, so these are the few, I think the few major clients. So whether it's, maybe I'm biased, learn the command line first and then use the GUI so that you actually know the commands behind it. Okay? So number three, Git log. This basically shows you the Git log. Once again, if you are using a GUI, most of them will already show you the Git branching thing. But how many of you use Git X? I also use Git X, so that's another GUI. So Git log itself, it's a command and maybe let me show you, maybe the rebuild. This is my alias, Git log, and it's just GL. And you can see that I have a decorated date relative format and yada yada. So you can format it in the way you want. And let me show you the rebuild SG Git log. So it looks a bit like this. So you can pre-defy it if you want. So you can work on command line as well. And if you search in Stack Overflow, you have many pretty Git log aliases that you can add to your bash profile or your shell profile. Great. Next is Git commit. And this is where I would love to hear from all of you. How many of you commit often and commit fast? Commit often, commit fast, yeah? So any little changes is committed and then you're on a fresh stage. How many of you tend to commit after a while, like after an entire feature is done? Is that challenging? Tests and to pass this. Yeah. I agree with you. Tests and to pass. Yeah. Hinting, linting, build tunes, everything has to pass. Commit messages. Especially if you're working in a team, I believe it's a good practice to have a consistent commit message pattern. Before I say two of my favorite, does anybody have some commit message patterns that you use in your team? Okay. So I'm going to count this in AngularJS contributing guideline. And I really like it. So what they do is they actually start with a word and a colon to kind of indicate what type of commit this is. Is it a feature? Is it a bug? Is it a refactor? And you can also find here the scope it and then they put the subject. Also in the subject, I find that they always say that start with a present tense verb like add blah blah blah or remove blah blah blah. And you kind of keep it consistent. The reason why AngularJS does it is to automatically generate change log. And I found this pretty cool. You know, like your commit message becomes a change log itself and you don't have to work manually to create a change log. So this is one of the favorite ones I use. And the second one is by Atom Editor. Oh, I love this one. You know why? You know, if you include this colon and the emoji thing and colon and then this, it comes up as an emoji in GitHub. This is only for GitHub. By the way, don't confuse GitHub and Git. This is a GitHub feature, not Git feature. But I love it. So there are tons of emojis here. If you ask around, I think I have a bad reputation for emojis and stickers. No. So if you look at the email that commits. Oh. It looks nice. It's pretty. Yeah, it's pretty. Then it shows up in your terminal as well. Unicode. Then it shows up in your terminal as well. Unicode. That is true. Emoji is here, right? Unicode. Okay, anyway. Choose the one with your team. The point is be consistent, okay? And use emojis or emoji cons or whatever. I think it kind of spices up and gives a little bit of light to your project. So this is the way I tend to do Git commits, messages. All right, next one. So let's say you go to your feature branch. You commit, commit, commit, commit, commit. And then you merge it back to master. How many of you practice squashing the commits, right? How many of you don't practice it? Like consciously don't practice it. And there are interesting points on both sides of the story. And I think it's just important to. So CJ, why don't you squash it? You love history. Yeah, that is basically a reason because they want to see every single thing. But what if you're testing things out, CJ? You know, like back and forth. It's a bit ugly, right? It depends on the size of the... Usually if you're looking at a very, very large thing, like 10,000, 20,000 developers. Yeah. You'll tend to want to... 10,000, 20,000? Yes. Okay. 20,000 developers. Like 20,000 or more. Okay, anyway. Okay, it's a huge company. You will want to squash the commits because a lot of time, they nobody care about the... When you make a commit, you'll have one commit, new feature, new feature. Yeah. And afterwards, another 10 commits are buff fixes, buff fixes, buff fixes, right? Yeah. Usually that's the case. Yeah. So when all this buff fixes, you can squash it and you just pretend that you have made a mistake. So basically when you look bad at your commit history, it's a lot neater. It's a lot neater, yes. Yeah. When you squash. So once again, choose a method. There's no... Yes. Another good thing about that is you don't want to keep any history in your history, file size small, when you're building a very, very large... File size small, don't get... So for example, Facebook's git, the goal is about 15 commits. I think so. And whenever you're running the status, it takes about one or two minutes to run. Wow. So it's also nice. Okay. Point again. So the point is, discuss with your teams, stick to a convention that suits your project and go with it. All right. Any other tips from anyone about git commit messages or commits? All right. Cool. Next one. Merge or rebase. I think it's a big debate. How many of you love to merge? Let's have more debates. Merge or... Okay. Merge in the merge camp. All right. In the rebase camp. All right. Another question. Why? Why merge camp? Maybe I should ask somebody. Claudia, why... Well, that's just recently switched. Okay. Great. So why did you switch from what to what? Because I went, so I should switch from merge to rebase, and I'm checking it out. Oh, you're just checking it out. Okay. That's a great thing as well. I mean, just experiment and see what it does. But why, why merge? I'm not rebase. Any of you? It feels awesome. It feels awesome. Why? It feels awesome when you... when you build a tree later on, it feels awesome. For merge? Yeah. Because it really shows you did something. Looks like you did something. Because rebase will basically destroy all your everything when it puts a master. Okay. Great. Why rebase? Can I have one answer? Why do you love rebase instead of merge? Easier to trace. Easier to trace. Okay. Cool. The other question is, when you have... Yes. So it's a very good topic. Yeah. Potentially, merge or rebase will be a new topic. Maybe, it's a very, very... Okay. Cool. We shall draw circles and arrows and have a debate about it then. All right. Great. No, I agree with you. I mean, it is a constant and people should know why they choose one over the other. So the next one is, I'm sure we have all had merge conflicts, right? So I want to know from all of you, what are the different methods you have used to merge and have a clean environment? How many of you use a GY? All right. What do you use, Sia? I use OpenDiv. OpenDiv, okay. P4 merge. P4 merge? Kdiv. Kdiv? Yeah, I have used Kdiv once. Does Emax come? Emax, but Emax is still considered middle, right? No, it's a... There's this thing called S merge mode, which highlights for you the different sections and then you can merge the two sections. Okay. All right. Since you have talked about Emax, come on, Vim, where are you? Give me. Yes. Are you spliced up, Vim? Okay. Okay. Good to know. Cool. Or if it, you can also do it manually, of course. You know, they come with, what are those calls? Is there a word for it? Merge conflict markers. Merge conflict markers. They're called carrots. Great. All right. So merge, release, merge conflict, choose your tool once again. All right. The next thing is hooks. How many of you use githooks? So, for those of you who are wondering, githooks are kind of shell scripts that lie within .git slash hooks folder. And I would love to hear from you what are some of the githooks you use. I used to do pre-commit hooks and I used to run my test until my test went over 200, 300, 400. I was like, I cannot run my entire test suite every time I do that. And just a couple of weeks ago, I changed it to pre-push. And it runs the test just to ensure that before I push, all my tests pass. But I would love to hear from you what are other githcommit hooks you use and for what purpose? Okay. Sorry? Up. It's for syntax checking, Python, files. Well, that's hinting, right? Yeah. Hinting. Hinting, and you use it for pre-commit. Pre-commit. That's pretty cool because if you do just hinting, then running the test. So you pre-commit and then you do hinting and minting. Okay. What? Yes, Sahil? So I had this problem that in my unit test, you can run only one or two unit tests if you want to exclude the other track. Okay. And I have this bad habit of committing that so when I push it, only one unit test runs on the build server. Right. So now I have a pre-commit book that checks that I have an excluded test and I'm running everything. That's, that's pretty cool. So you're skipping, skipping some tests, right? And you do that. Yes, so just go through all the files and make sure that I haven't described that only or hinted that only anyway. So this is in your pre- commit. Commit. Commit code, right? And you have just a batch like grep or something. Just a grep and then skip. That's pretty cool. I think I'm going to use that. Thanks Sahil because I have done that before. Awesome. So any other? Yes. Equipointment. Post-receive book. Post-receive, okay. Which will pick up jobs. Interesting. It's very similar to how GitHub have their web books. Ah. Okay. That's a post-receive book. Post-receive book. Okay, cool. I learned something too. Anybody else? In Debian, we also have post-receive books to announce things about the Irish chat. Ah, that's pretty cool. So you can hook to Hubert, you can hook to Slack. Yeah, all the chat ideas have come, right? Yeah. And mailing lists. And mailing lists. That's right. Awesome. So any of you do deployments with commit hooks? Yeah. Which hook do you use? Same. Same. Okay. Cool. So git hooks are very powerful if you haven't used it with your team. Have a discussion and use it. I have one last question for any of you. So the thing is that this pre-commit hooks actually are not part of the git repository, right? So where do you use it? Is it in the read me file? I write them down in my read me file. Oh, so that's common for all the projects, I guess. Yeah. Actually, in the case of Debian, there's a script called setup repository for every new package that we do. Interesting. So you call the script with your repository name and it just puts all the hooks there for you. Interesting. So have a common repository for all the projects. It's not common repository. It's one repository. Okay. One repository. Okay. It's just all in the same directory. We keep in the script folder. So we have a shell script. Okay. A shell script will just be the install of it. It basically will just come in the latest pre-commit pre-commit hook. Pre-commit or post-commit or whatever. Next one. Git tag. Semantic versioning. How many of you follow that? Can you explain what's git tag? Git tag. Okay. So basically your commit, right? You can have another attribute called tag and you can give it a number and you can also have a message. So git tags are typically the way I and my team use is every push to the production is tagged. So it's basically kind of a mock-up. Should I really mention it? Our Git so should I just say it? Our first slide did not follow semantic versioning. It was 0.1.0. So semantic versioning 2.0 is 1.0.0. So for those of you how many of you have heard of git semantic versioning? All right. So for the rest of you semantic versioning means you have three digits. So something the first one is a major API change which means backward incompatible. Maybe I should show you the come on. Okay. Same bar. So the first digit means it is a major API change which is backward incompatible. The second digit means backward compatible. It's a feature and the last one is switches. So usually the way I do tagging is following semantic versioning. So it kind of tells people that hey if I bump up the middle number it means I have a new feature but it is backward compatible. And the way I create like I said the way I use the tag is that every push to the production has a tag and this is how not always my version so how all of you use git tag or do you use git tag? Is there any other way you use git tag? Other than kind of marketing production deployment? Branches. Branches. You use git tag for branches. Branches as version. That's interesting. So you don't use git tag. Branches as yeah. That's right. That's right. Is there any other way you don't use git tag? I don't know. You can use git tag as as as as as as as as as as as as as as as as as as as as as as as Okay, CJ said that you should alias it to git praise because they're after all your team members. Okay, so for all of you out there, I don't think I've ever used git blame seriously except for open source repositories, not to see who has done it but to see when was the last change. But I would probably take this chance to ask all of you, what are any horror stories from which we can learn something? Anybody wants to share? Yes? Not exactly a horror story. Sure. Interesting. Okay, cool. Any other stories for git blame or just working with git on your team? Sometimes git blame is good for finding out the context, how, who, what we wrote that quote, why we wrote that. How many months ago? Yeah, may not be as far back as that but it's a very recent change that all of these, this is a breaking change for the team. So what was the reason behind it? Why it was not discovered in the point of view of the division test and stuff. So it's a good way to look for reasons to find out why. So actually when you testing and you have a lot of mocking, there are a lot of mocks and stuff, which are contracts, which will change the contract and something great to do, find out why. There will be a good reason behind it, like say some deserialization doesn't work, some work has to be done. Awesome. Yes, Claudio. Maybe as a question to everyone, especially to you, I mean, now that we, we could keep playing, for example, we have so much metadata about the code, the way it works. Do you think that makes comments sometimes less necessary? Because what you just said, when you want to know why was this breaking change introduced, the traditional idea would be there should be a comment in the code. So this is why we did it. If you have to use the same language, maybe that's the intention that we have to, like if you don't comment such things, like ideas. I think in AirJar, you value communication. So you face-to-face communication rather than writing contracts and saying you didn't do this, right? So you rather talk to the person and find out why, but sometimes description may not be detailed, right? Yes, Joshua? Another way to use the same language is that you have a father who wrote code at the start and now they have my hands up. So it becomes a game, like, where you sit in. It's the father's code still in the code base. That's interesting. That's very interesting. I think last week was Microsoft's 40 years, right? And Paul Allen, I think he did something like that. He went back to the very first comment of the windows and showed Bill Gates and him writing that code. So it's pretty interesting to see the founder's code. Cool. So it's like going back to history, the starting of the code base. Like, anything else you want to share about given teams? Or did I miss anything, 39th? Yes. Cool. Awesome. Going back to your point on squashing history. So I was working on a really large project and then we did a bisect and there was an issue we didn't figure out what it was that we squashed it in. Okay. So it came, that's one downside to squashing documents, I guess. Right. Because when you want, when there are issues down the road, especially as we go further next, you don't know where exactly the code fails because sometimes the case of integration doesn't pick up on issues that fail, like tests that fail over the months. Fantastic. Right. Any last comments about Gates and working with teams? How many of your teams prefer other than Gates? Oops, or is this the right question? It's a perfectly valid question. Perfectly valid question. We prefer not Gates. Alright guys, Sheld. Yes. Comment messages that you can actually tie it up with an issue tracking system. So if you have comment messages like, you use Pivotal Tracker and you tie it up with Pivotal Tracker, you just put a square bracket through the cache called by the story number. You actually add comments to Pivotal Tracker. It prepend it like finishes of the livers. You actually change the status of that story. So you're working with GitHub issues. So learn those and append stuff to your comment message and it will be automatically closed. That's a fantastic thing. So on the subject of GitHub issues and using something like Pivotal Tracker, there are like third party GUIs that try and make the GitHub issues look more like Pivotal Tracker story lengths. What are your opinion, your recommendations? I prefer GitHub issues by itself. I think it based on preference. But this is a good point. There is something called Kanban or something like that. Kanban looks like Waffle Lio. Yeah, Waffle Lio. Exactly. Waffle Lio that hooks on to GitHub issues. The other day you showed me Zen Hub. Zen Hub. And it kind of arranges into like fellow boards. Zen Hub.com. Zen Hub.io. You use Gira as green hopper. Yeah, Gira. Pivotal? Bitbucket. Bitbucket is Gira, right? Alas. Alas. Alas. They have a Bitbucket issue. I don't know why it's the name of it. It's Bitbucket dash project of Pivotal Tracker. Okay. Basically, similarly Kanban style, Schroeder box style where you can just drag and drop your issues from one link to the last one. Right. Fantastic. That is integrated only to Bitbucket and only Bitbucket. So I guess they're always pros and cons and you have to evaluate with your team. Yeah, that's fantastic. It's basically the project management side of things. Okay, great. Any other tips, tricks? All right. If not, thank you very much for sharing your ideas and discussions.